Also, das mit'm Einlesen geht langsam vorran (war in letzter Zeit vorwiegend damit beschäftigt alle Lese-/Schreibgrundroutinen diesbezüglich umzustellen
)
Ansonsten hab ich mal was getestet, welches die ganze Zeit vernachlässigt wurde ...
und zwar das Suchen von Nodes.
z.B. alle 10.000 Nodes in zufälliger Reinfolge aus einer Reihe von 10.000 Subnodes rauszusuchen und das ersten und einzige Attribut auszulesen dauerte ~6,7 Sekunden (bei mir)
War mir etwas viel, drum hab ich da heut noch Einiges geändert
und einen Hashvergleich vor gewisse Stringvergleiche vorgeschaltet.
OK, so sehr viel Zeit konnte ich damit dann doch nicht rausholen, wie zuerst erhoft (mal sehn wo es noch hängt), aber fast doppelt so schnell ist auch schön
Dieses meinte dann das Testprogramm (siehe SpeedTest.dpr Post #1) dazu:
Code:
SetProcessAffinityMask: OK
use QueryPerformanceCounter
precreating used strings - do not create and convert this within the measuring
create:72
fill TXMLFile with 10.000 nodes with attributes and search nodes
create:0 fill:602 search:3268 free:8
fill TXMLDocument with 10.000 nodes with attributes and search nodes
create:3 fill:6394 search:146699 free:0
press [enter]
Obwohl, wenn ich mir das jetzt so betrachte ... gegenüber dem MS-XMLDOM ist/war es ja doch noch recht flott unterwegs.
Sind durchschnittlich 0,33 Millisekunden zum raussuchen eines Knotens aus 10.000 eigentlich schnell/langsam?
(hab jetzt noch keine Vergleichsmessungen an anderen Listen vorgenommen oder solche Zeiten irgendwo gelesen)
Und ich geb's zu ... zu dieser Optimierung hatten mich alzaimar's
Hash-Tabellen verleitet, welche ich noch etwas im Kopf rumschwirren hatte.
Zitat von
alzaimar:
Die CRC32-Hashfunktion wurde durch die wesentlich schnellere ELF-Hash Funktion ersetzt.
hab mich zwar nun auch für 'nen ELF-Hash entschieden, obwohl der in meinen Tests fast genausoschnell wie ein CRC32 war
(durchschnittlich bei über 20 Byte war CRC32 ein bissl flotter und darunter ELF)
nja, so brauchte ich zumindestens nicht noch 'ne Hashtabelle mit unterbringen
und der ELF ließ sich durch kleine Umbauten (incl. ein/zwei Extras für meine Bedürfnisse) direkt auf's
Unicode (2 Byte pro Durchgang der Berechnungsschleife) loslassen und das fast nochmal doppelt so schnell (in diesem Sinne war es dann doch wesentlich schneller
)
Angang siehe Post #1
[edit] Anhang (Post #1) durch 'ne
Ansi-Version ersetzt ... wo kam denn das UTF8 schonwieder her?
