boost::pool performance/alternative gesucht
-
Shade Of Mine schrieb:
Die ganzen Allokationen kann man killen indem man die XML Datei in den Speicher mapt und dann nur nocopy-strings darauf fährt, also keine neuen allokationen machst sondern direkt den auf den gemapten daten arbeitet.
rapidxml, wie mein vorredner erwähnt hat, macht das zB genauso.
Also jetzt wirds offtopic, XML Parser sind noch mal ein eigenes Thema.
Und gerade da kann rapidXML eine Lösung wie Xerces nicht ersetzen, fehlende Valdierung, Namespacesupport, SAX etc. All das kann Rapid zur Zeit nicht.
-
@pool
Danke für deine ausführlichen Infos :), da sieht man was ein vollständiger XML parser leisten muss. Ich hab da ja nur so einen primitiven selbstgebauten mini-parser der nur einfache Tags auslesen kann, weil die zu verarbeitenden Daten auch nur einfachste Strukturen aus einem uralten Fremdprogramm sind. Ist natürlich was ganz was anderes wenn man weitere Komponenten einsetzt und XML auch richtiges XML ist (http://www.virtualdub.org/blog/pivot/entry.php?id=251)
Zu den Listen: Ich bin da kein Experte aber ev. möchtest du ja weitere Container einsetzen.
vector ist ja nur ein einfaches Array bei dem Zugriffe schnell aber suchen, einfügen und löschen langsamer sind.
set und map müssten binäre Bäume sein.
Da kann dir vielleicht eine Hashtable mit einer guten Hashfunktion helfen [O(1)] mittels boost::hash und unordered_set. Das ist wieder das Schöne an C++ - man kann gerne mal einen Container durch einen anderen tauschen und ein paar Tests machen, ob es besser wird
lg XOR
PS: @Shade Of Mine: Zumindest der XML-Parser setzt bereits String-Verweise statt Kopien ein ... aber ... Hmm ... die Files in den Speicher zu mappen ... könnte das mein Gral sein
... probier ich mal ... ist sicher effizienter als alle Files einzeln zu öffnen und in den Speicher zu kopieren.
-
Also unordered_map und unordered_set hat jetzt wirklich noch mal was gebracht, wenn auch wenig.
Problem ist aber, das ich auch Solaris8 als Plattform habe, und boost wohl mit so einem alten Compiler nicht baut. Wäre nämlich auch im Programm selber nett wenn man das nutzen könnte, da gibt es einige Klassen welche von einer std::list<T*> erben.
Das könnte man Prima durch ein Multiset ersetzen.Und zu den Containern: Vector ist wegen seines Kopierverhaltens und Speicherverbrauch hier keine Alternative. std::list ist besser, aber std::set ist da mit dem binären Baum einfach schneller.
-
pool schrieb:
Also jetzt wirds offtopic, XML Parser sind noch mal ein eigenes Thema.
Und gerade da kann rapidXML eine Lösung wie Xerces nicht ersetzen, fehlende Valdierung, Namespacesupport, SAX etc. All das kann Rapid zur Zeit nicht.Man muss immer ein trade-off zwischen features und performance machen. aber nocopy strings sind ein super weg um zuviele allokationen zu vermeiden. das alleine ist zB kein grund keine validierung, ns support, etc. zu haben...
-
Shade Of Mine schrieb:
pool schrieb:
Also jetzt wirds offtopic, XML Parser sind noch mal ein eigenes Thema.
Und gerade da kann rapidXML eine Lösung wie Xerces nicht ersetzen, fehlende Valdierung, Namespacesupport, SAX etc. All das kann Rapid zur Zeit nicht.Man muss immer ein trade-off zwischen features und performance machen. aber nocopy strings sind ein super weg um zuviele allokationen zu vermeiden. das alleine ist zB kein grund keine validierung, ns support, etc. zu haben...
Ja, mag ja sein. Aber 500 mb lassen sich so halt nicht wirklich parsen. Das ist zu Speicherintensiv.
Und rapidxml mit xerces zu vergleichen ist Äpfel mit Birnen zu gleichen.
Mein Problem ist ja, das wir bereits Xerces nutzen, und die Features benötigen.
Aber wie gesagt, das ist dann auch wieder Offtopic.Interessant wäre ein Parser welcher das Speicherverhalten und andere Dinge über eine Strategy einstellbar machen würde. Der Parsingteil ließe sich zb. mit boost::spirit machen, aber support von DTD, Schema, Namespaces ist alles andere als Trivial.