'nen besonderen Grund gibt's nicht, aber
- ich seh in einer Optimierung keinen Vorteil, da hier der Datenträger mehr ausbremst, als das "unoptimalere" Speichermanagement
- dann hat man heutzutage einen "optimaleren" Speichermanage (FastMM) in Delphi integriert (OK, in Delphi 7 ist der noch nicht standardmäßig drinnen), welcher praktisch deine "32er-Schritte" erledigt und ich somit diese Speicheroptimierung einfach vom MM erledigen lasse, anstatt es selber zu implementieren (hat man gleich noch eine Variable eingespart)
- und Zuletzt: ich war Faul und hab mir diese Optimierng gespart (dazumal sie ja eh nicht viel bringt ... siehe Punkt 1 und 2)
Ja und das mit dem "Dateipfaden aus den SearchRecs zusammenbauen", da kann man geteilte Meinung sein.
Hat Beides vor und Nachteile.
Pfade zusammenbauen:
+ geringerer Speicher, da man nirgends die langen Namen speichern muß
- braucht ein paar Nanosekunden länger, da man diese Namen erst zusammensetzen muß
Pfade speichern:
- mehr Speicher, da ja irgendwo diese Strings gespeichert werden müssen
+ ist ein paar Nanosekunden (pro Auslesevorgang) schneller, da die Namen schon fertig zusammengesetzt und somit direkt abrufbar sind.
Wobei das Mehr an Speicher hier wohl nicht viel auffällt, da ja die Pfadtiefe nicht extrem groß ausfallen dürfte.
Wie gesagt, der "langsame" Datenträger bremst eh dermaßen aus, daß Optimierungen im "superschnellen" Arbeitsspeicher nicht wirklich auffallen dürften.
Das ist praktisch der tägliche Kampf:
> lohnen sich Optimierungen und wenn ja, wie viel lohnt sich wirklich
Man kann sich ja soweit zu Tote optimieren, daß da massig Zeit draufgeht und am Ende der Code auch noch unübersichtlicher und schlechter wartbar wird.