Allerdings hat man dort keinen Zugriff auf die Hashs.
Delphi-Quellcode:
type
TMyRec = record
ID: Integer;
Value: String;
end;
TIDList := TList<TMyRec>
Wie schnell muß es denn sein?
In der
DP gibt es uch noch irgendwo Hashlisten.
Aber wenn es nicht unbedingt extrem schnell sein muß, dann speicher doch die ID in den Objects der TStringList.
In der Liste noch ein LastID gespeichert und jeweils dem neuen Eintrag die nächste ID verpassen, somit könnte man auch Einträge löschen, bzw. den Index unbeachtet lassen.
Im GetFieldName dann die Liste durchgehn und nach der ID suchen ... die paar Integervergleiche dürften ja auch so schon schneller viel sein, als die Stringvergleiche, auch ohne eine sortiete ID-Liste.
Ah, TDictionary ... mit fiehl nur noch sowas wie TKeyValue<> ein, aber keine ganze liste
Bildet das uch eine Hashlist? Ansonsten kommt das etwa auf's Gleiche raus, wie ein selbstimplementiertes Strings+Objects der TStringList.
PS: Bei der THashedStringList dürfen vermutlich keine Werte doppelt vorkommen, also wenn man auch gleiche Strings auseinanderhalten will, bzw. wenn sich der Hash/ID nicht ändern darf, wenn man den String ändert.
[add]
Und zu deiner Speicherersparnis:
250000 * ((12+1 Zeichen) * 2 ByteProChar + mindestens 12 Byte Verwaltungsoffset)
250000 * ((12+1) * 2 + 12)
9500000 Byte
9,1 MB
OK, gegenüber 1 MB, mit der Integerlistenvariante, klingt das schon irgendwie "mehr", aber was sind heute schon 10 MB?
PS: Wo kommen die Strings denn her?
Strings besitzen eine Referenzzählung, also wenn sie alle aus den selben 500 Quellen kommen, dann belegen die insgesammt sogar weniger Speicher, als deine Integervariante, da die zusätzliche ID/String-Liste eingespart wird und SizeOf(String) = SizeOf(Integer)
Und wenn das alles Konstanten sind, dann belegen die sogar noch weniger Speicher, da die Stringdaten nicht wirlich im rbeitspeicher liegen, sondern in der EXE verbleiben, bzw. in deren Datenbereich, welcher nur als eine Art MMF temporär im
RAM liegt.