Delphi vs. Freepascal und THashedStringList

[jaenicke]

Zitat von DelTurbo:

Ja Delphi 2007.

Es wurde an einigen Stellen massiv an der Geschwindigkeit gearbeitet seit Delphi 2007 (unter anderem bei Threads), von den vielen anderen Verbesserungen ganz zu schweigen...

[himitsu]

Wurde FastStrings 2009 oder schon 2006 teilweise in Delphi übernommen?
(finde nicht mehr wann es war, aber 2007 hatte der originale Entwickler die Entwicklung eingestellt)

Mit 3% (div 33) der Daten dauert es nicht so lang.
Das mit dem "Selbsbau"-Hash findet manchmal mehr, wegen Hash-Kollisionen, zu kleinem Hash und da nicht nochmal der String verglichen wird.
Und das mit den Generics geht erst nach D2007, bzw. im FPC vermutlich etwas anders.

Code:

// 685.158 in 2.313.748
TArray.BinarySearch       342579  0,97
TArray.BinarySearch.Hash  342708  0,39
TStringList               nach über 3 Stunden abgebrochen und mit weniger versucht
TStringList.Sorted        342579  3,05
THashedStringList         342579  448,36
THashedStringList.Sorted  342579  334,23
TList<>                   ...

Code:

// mit DIV 30 = 22.838 in 77.124
TArray.BinarySearch       11419  0,01
TArray.BinarySearch.Hash  11419  0,01
TStringList               11419  153,13 (3min)
TStringList.Sorted        11419  0,05
THashedStringList         11419  0,11
THashedStringList.Sorted  11419  0,11
TList<>                   11419  9,30
TList<>.Sorted**          11419  9,31
TDictionary<>             11419  0,00

Fazit:
Für normale Mengen an INI-Einträgen ist die Delphi-THashedStringList absolut schwachsinnig.
Sortiert ist eine normale StringListe wesenlich schneller und selbst unsortiert ist sie in normalem Umfang immernoch schnell genug.

[Stevie]

Zitat von himitsu:

Für normale Mengen an INI-Einträgen ist die Delphi-THashedStringList absolut schwachsinnig.
Sortiert ist eine normale StringListe wesenlich schneller und selbst unsortiert ist sie in normalem Umfang immernoch schnell genug.

Ne sortierte StringListe kannste aber nicht modifizieren und wieder in eine Datei schreiben, so dass nur die geänderten Stellen unterschiedlich sind

Das Problem ist, dass schon damals viele der RTL Entwickler von Datenstrukturen und Algorithmen und schon gar nicht von Hardware Effekten (Cache Verhalten und Co) nen Plan hatten. Nativ kompiliert, da wird das schon schnell sein, woll

[himitsu]

[doppelpost deleted]

[himitsu]

Och, es muß ja nur die Suchliste sortiert sein.

Was auch so manche Komponente so implementiert.
Die originale Liste und zusäzlich ein sortierter Index, mit den Suchmustern und ihren Indizes zur eigentlichen Liste.
Pssst: Wozu man wohl das Objects der TStringList missbrauchen können würde? (oder gleich ein TDictionary<Key,Index>)

[p80286]

Zitat von Stevie:

Das Problem ist, dass schon damals viele der RTL Entwickler von Datenstrukturen und Algorithmen und schon gar nicht von Hardware Effekten (Cache Verhalten und Co) nen Plan hatten. Nativ kompiliert, da wird das schon schnell sein, woll

Hmmm ist das jetzt so unter uns bei nem Bierchen gebrummelt oder hast Du konrete Informationen?

Gruß
K-H

[himitsu]

Zitat von p80286:

Hmmm ist das jetzt so unter uns bei nem Bierchen gebrummelt oder hast Du konrete Informationen?

Wenn du dir StringReplace ansiehst, was da passiert, wenn mehr als Einwas ersetzt wird,
oder Format, wo mit einem statischen Puffer auf dem Stack gearbeitet wird, da wird dir schlecht.

Oder nimm dir mal den originalen DelphiMM vor. Ein bissl mehr hätte man da schon machen können, ohne gleich so weit zu gehn, wie der FastMM.
Gut, der ist "optimaler" für kleine Speicherblöcke, als das was Windows dort nativ (VirtualAlloc) anbietet und wesentlich schon flotter als der MM der OLE32.

Und auch viele andere StringFunktionen waren nicht grade "optimal".
Auch wenn nur Bruchteile der FastStrings übernommen wurden, war das Ergebnis schon um welten Besser, als die Originale, an denen man Jahrzehnte praktisch nie etwas geändert hatte .... es lief ja, also warum was tun.^

Den StringHelper hat man sich von anderen Programmiersprachen abgeguckt und dabei nur das Interface grob kopiert, aber natülich nichts davon an Pascal und dessen Verhalten angepasst, womit dort nun auch Einiges echt grausam aussieht, obwohl es nagelneu ist, außerdem dachte man nicht weiter und hat somit vieles vergessen, wo man sich fragt wieso gibt es das nichts, obwohl es einem sofort in den Kopf kommt.

[Luckie]

Bitte beim Thema bleiben.

[p80286]

Zitat von Luckie:

Bitte beim Thema bleiben.

MM nach ist das das Thema "Hat die RTL noch Optimierungsbedarf?".
Für mich hat sich das jetzt bestätigt, also weiterhin nicht alles als gegeben hinnehmen.

Gruß
K-H

P.S.
Make it run, make it reliable, make it fast.

[Stevie]

Zitat von p80286:

Hmmm ist das jetzt so unter uns bei nem Bierchen gebrummelt oder hast Du konrete Informationen?

Einfach mal RTL Source Code studieren und ein bisschen (mehr maß ich mir gar nicht an von mir zu behaupten) Wissen über asymptotisches Verhalten, konstante Faktoren (vor allem von der Hardware beeinflusste) haben und ggf in den generierten Assembly Code zu schauen, um zu merken, dass man z.B. öffzig unnötige temporäre Strings gebastelt hat mit ner naiven Implementierung.

Zitat von p80286:

Make it run, make it reliable, make it fast.

Für Standard Bibliotheken sollte allerdings zwischen 1 und 2 kein Release erfolgen, sondern erst nach 3. Nur leider stoppt nach 1 oft jegliche Entwicklung und fast alle Anmerkungen bzgl 2 und 3 werden als "new feature" abgetan.