Speichernutzung: array of record vs. TObject (TList usw.)

[Robert_G]

Zitat:

Zitat von jensw_2000

Resultat: Bei 40000 Datensätzen 300 MB RAM und 350 MB Auslagerungsdatei ...
Das klingt zwar immer noch recht hoch, aber im Vergleich zum Ausgangspunkt ist das eine enorme Verbesserung.

Das klingt wiklich hoch...
Hast du dir mal ausgerechnet, wieviel es theorhetisch sein *sollte*.?
Speicherfragmentierung ist ein ernsthaftes Thema. Bevor ich auf den .Net Zug gesprungen bin (und bevor ich den NexusMM kannte ;) ) hat mich das doch sehr häufig erwischt.
Gerade wenn es darum ging wenig normalisierte Eingangsdaten aufzubereiten und auf zig Tabellen aufzuteilen.[1]
Da das bei 40.000 Zeilen zulange dauern würde, hatte ich es immer in speichergerechte Häppchen aufgeteilt, welche auf einem Multi-CPU und/oder HT P4 auch (in Grenzen) gleichzeitig aufbereitet werden können. :)


[1]In der Pre-XML-Zeit war es nicht ungewöhnlich, dass Eingangsdaten so übel strukturiert ankamen, dass ich eine "Zeile", nomalisiert, in 40 Tabellen und mehr packen musste/konnte.

[BlackJack]

Zitat:

Zitat von Nogge

@BlackJack: Ich dachte immer nur, dass die Zeilenanzahl (wenn überhaupt) die Größe der *.pas, *.exe ausmacht. Ersetzt der Compiler nicht einfach die Stellen im Source Code, wo die Procedure steht, mit dem in der Procedure enthaltenen Code?

nene, der code der proceduren steht nur ein mal in der exe, und dieser code wird dann immer aufgerufen, wenn die procedure benutzt wird. spart halt bei vielen aufrufen enorm platz. wenn der platz keine rolle spielt, sondern eher die performance, dann hat z.b. C++ (und ich glaube seit neuestem auch Delphi2005) die möglichkeit, inline-proceduren zu deklarieren, die werden dann tatsächlich immer im source eingefügt. spart halt jedes mal den aufruf (sind aber nur pro aufruf eien handvoll CPU-zyklen gespart).
allerdings habe ich damit unter delphi schlechte erfahrungen gemacht - nur weil der compiler das zulässt muss es noch lange nicht heissen dass es dann auch ohne abstürze funktioniert (war bei mir zumindest so).

[Jens Schumann]

Zitat:

Zitat von BlackJack

Zitat:

Zitat von Nogge

Und mein Freund schreibt lieber 5mal dasgleiche in seinen Code, als einmal in eine Procedure...

das ist schön blöd.
1. wenn er dann was ändern muss muss er es 5x ändern
2. benötigt das rund 4 mal so viel speicher wie eine procedure
3. ist das einfach nur doof.

Das muss nicht unbedingt blöde sein. Wie immer gibt es für sehr spezielle Fälle auch Ausnahmen.
Z.B. Nimm Dir einen Algorithmus und trimme den auf Geschwindiglkeit. D.h. das einzige was zählt ist die Geschwindigkeit. Wenn der Code, den Du in einer function oder procedure hast, innerhalb des Algo in einer oder mehreren Schleifen läuft kann es durch aus sinnvoll sein den Code direkt in den Algo zu schreiben. Auch wenn dies mehrfach der Fall sein sollte. Dann fällt der procedure Aufruf weg. Das kann die Geschwindigkeit des Algo entscheidend erhöhen.
Je öfter die Schleifen durchlaufen werden desto höher ist der Geschwindigkeitsgewinn.

[jensw_2000]

@Robert_G
Ich werde den zu erwartenden Speicherzuwachs nach meinem Urlaub durchrechnen.
Testweise werde ich den SQL-Server auch mal auf eine andere Maschnine auslagern, da
der sich während des Imports auch eine Menge Speicher greift. Der tatsächliche Speicherzuwachs ist sonst rechr schwehr zu bestimmen.

Generell habe ich den Import ohnehin schlecht gestaltet, weil immer jeweils ein Datensatz ausgelesen, geprüft, normalisiert und dann in dir DB geschrieben wird. Beim Schreiben in die DB prüfen sie Stored Procs auch noch ein paar Dinge ab. Ein Bulk Insert der normalisierten Daten sollte da deutlich effektiver sein.

Heute gehe ich da aber nicht mehr bei. Mein Flieger geht um 2:15 Uhr :dancer:

Danke,
Jens

[Nogge]

Zusammenfassend:
@BlackJack: Also spare ich durch Procedures (bei mehr als einem Aufruf) definitiv Festplattenspeicher (was mir eigentlich egal ist) und RAM-Verbrauch (worum es mir die ganze Zeit geht)?

Ich möchte außerdem nichts ableiten oder weitere Methoden nutzen, ich will lediglich einen schnellen Zugriff auf meine Daten im record (s. paar Posts davor) und (das wichtigste!) eine geringe Beantspruchung des RAM durch mein Programm.

[BlackJack]

@Jens Schumann:
dass man da zwischen geschwindigkeit und speicherbedarf abwägen kann, war mir schon klar (soetwas hatte ich ja gestern nacht noch gepostet), nur wenn Nogge schreibt, dass sein Freund grundsätzlich immer den code 5x schreibt statt eienr procedure, dann wird man doch wohl leise zweifel andeuten dürfen, nicht wahr? ;)

@Nogge: so ungefähr könnte man das sagen. wobei auch die RAM-belastung keine rolle spielen dürfe, wenn du nicht proceduren mit mehreren tausend zeilen "auslagerst" - auf die paar kb kommt es auch nicht an.
wobei noch zu erwähnen ist, dass du es sehr viel schwerer hast, deinen code zu warten oder zu erweitern, wenn du ohne proceduren arbeitest - hast du eine procedure, musst du den code nur einmal ändern, benutzt du keine proceduren, musst du überall in deinem projekt suchen, wo du den fraglichen code benutzt, und den dann ändern. und gross eine andere möglichkeit hast du ja nciht, da inline-proceduren wie gesagt erst ab Delphi2005 unterstüzt werden, und das auch (meiner meinung nach) mehr schlecht als recht.

aber ich würde dir wirklich raten, so viel wie möglich mit mehreren kleinen, übersichtlichen proceduren statt mit riesigen code-batzen, die du wauch noch mehrmals im code verwendest, zu arbeiten. die von Jens erwähnten geschwindigkeitszuwächse dürften erst ab mehreren millionen oder millarden proceduraufrufen in extrem zeitkritischen anwendungen ins gewicht fallen - wie gesagt braucht ein (moderner) Processor, um eine procedure aufzurufen und nachher wieder zum ursprungsort zurückzukehren, keine 10 takte.