ListView > VST: wieviele Klassen verträgt ein Programm/VST

[Glados]

Es steht bald ein großer Umzug bevor. Ich werde ein TListView in Rente schicken und durch ein TVirtualStringTree ersetzen.
Aktuell speichere ich, oh Schande, die Daten direkt im TListView. Mit dem VST dann natürlich in Klassen-Objekten, was alles in einem anderen Testprojekt schon vorbereitet ist.

Ein paar Fragen bleiben aber:
erste Frage: wieviele Klassen verträgt ein Programm? Pro VST-Eintrag brauche ich eine Klasse (ist ja logisch) und es kann ganz grob zwischen 0 und 100 VST-Einträge geben.

zweite Frage: ich möchte mein Programm so sauber wie mir möglich gestalten was das VST angeht.
- ALLE Daten einer Ini-Section (eine Ini-Section = ein VST-Eintrag bei mir), sodass ich an anderen Stellen nur ins Klassen-Objekt gucken muss und zack habe ich meine Daten
oder zu Programmstart nur das VST mit den Texten bestücken (Col1 bis ColX) und den Rest immer dann aus der Ini laden wenn er gebraucht wird?

Ist ersteres technisch vom Arbeitsspeicher-Verbrauch möglich? Eine Ini-Section kann in etwa 200 bis X00 Bytes groß sein.
Ich weiß ja jetzt nicht wieviel das Programm dann dafür reservieren würde. Aber 200 Bytes pro VST-Eintrag sicher nicht.
Ein VST-Klassenobjekt wird einige strings, integers und Booleans haben, aber es werden auch strings geladen, die dann mit meiner eigenen Ini-Interposer-Klasse direkt in ein Enum gesteckt werden.

[pertzschc]

Zitat von Glados:

Ein paar Fragen bleiben aber:
erste Frage: wieviele Klassen verträgt ein Programm? Pro VST-Eintrag brauche ich eine Klasse (ist ja logisch) und es kann ganz grob zwischen 0 und 100 VST-Einträge geben.

Bloß mal ganz theoretisch: Du erzeugst Instanzen von Klassen (keine Klassen selber) und davon so viele, wie Du benötigst bzw. angezeigt werden sollen. Das ist im Bereich kleiner 1 Mio. vollkommen unkritisch bezüglich Speicherauslastung.
Grüße, Christoph

[mensch72]

VST = (grob) ein IndexPerElement, wo DU SELBST per GetValue/SetValue Event alles nötge live liefern, bzw speichern musst.

Kümmere dich also um eine saubere interne eigene Datenhaltung. Wenn du alles im Ram halten kannst dann mach es.. eine TObjektlist oder doch besser ein Dictionary also "KeyIndex for TObject" ist da ein erster Ansatz. Wenn eh nicht alle in den Ram passt, dann besser gleich die Daten Live per SQL aus einer indexbasierten Query geholt und auch per Index über Insert/Update Live aktualisiert.


Tip: Vergiss besser dein "INI" Konzept, wenn dann aktuell sowas als TObject<->JSON (Objekt)Serialisierung am besten mit aktuellem Delphi realisieren, sonst die RTTI dazu benutzen.
Satt purer INI Files oder HandMade XML dann lieber ne Mini (SQL)DB mit nem Index und nem Blob für die typisierten (Class)ObjectData als JSON.

[Glados]

Zitat:

Wenn du alles im Ram halten kannst dann mach es..

Genau das frage ich oben doch, denn ich weiß nicht wieviel das an RAM belegen würde.

Zitat:

Tip: Vergiss besser dein "INI" Konzept

Meinst du damit die Datenhaltung in Ini-Dateien? Nein. Dabei bleibe ich. Ich halte nix von fast kryptisch anmutenden Dateien, die die Nutzer ggf. nicht selber mit Notepad bearbeiten können.
Das ist aber nicht das Thema und hat für mich 0 Wichtigkeit.

Wichtig sind nur die beiden von mir gestellten Fragen für mich + wieviel RAM bei ~300 Bytes pro Ini-Section, ein paar Strings, Integers und Enums und das alles maximal 100x reserviert werden könnte.
Es sind keine komplexen Datentypen dabei.

[mensch72]

Ich denke Du und deine Kunden seid eventuell doch durchaus leicht anpassungsfähig
- selbst in einer Ini Datei kannst du per Section weiter einen "Key" und ein "(JSON)Value" als String speichern
- das kann man wenn man möchte jederzeit weiter per simplen Notepad als Texteditor bearbeiten
- die "automatisierte" ObjectSerialisierung wäre doch mal was "besonderes", denn das macht dir das Leben und den Source einfacher
- Ob nun ein Blob in einer SQL DB, oder eine ValueEintrag in einer Ini-Section... das ist doch völlig wurscht!

[Glados]

Welche Kunden? Hab ich keine.
Bitte lasst das Thema Ini sein. Das interessiert mich doch gar nicht und ich werde nichts anderes verwenden.

[mensch72]

jo, wir haben auch noch ein paar INIs das is schon weiter ganz praktisch

Also nochmal:
willst du unbeding weiter selbst KeyValuePerKeyValue für deine IniSections programmieren, oder haste nicht mal Lust dir da eventuell das Leben etwas zu erleichtern.
Versuch macht Kluch... probiere doch einfach mal was raus kommt und ob das noch für dich akzeptabel per Texteditor zu bearbeiten ist.

Die Bytes per Eintrag sind in deinen genannten Anzahlen heutzutage völlig wurscht!

[Glados]

Zitat:

willst du unbeding weiter selbst KeyValuePerKeyValue für deine IniSections programmieren, oder haste nicht mal Lust dir da eventuell das Leben etwas zu erleichtern.

Keine Lust Ich bleibe vorerst bei Ini. Das ist einfach genug.

Zitat:

probiere doch einfach mal was raus kommt und ob das noch für dich akzeptabel per Texteditor zu bearbeiten ist.

Ich brauche nichts auszuprobieren. Mit dem Ini-Format habe ich das für mich akzeptable Format gefunden.

Zitat:

Die Bytes per Eintrag sind in deinen genannten Anzahlen heutzutage völlig wurscht!

Was könnte denn da auf mich zukommen? 10, 20, 30, ... 100 MB im "Taskmanager" nach Programmstart bei 100 VST-Einträgen?

[hoika]

Hallo,
da du ja extrem beratungsresistent bist.

Warum probierst du deinen Ansatz nicht einfach aus?

[Glados]

Was hat es bitte mit beratungsresistent zu tun, wenn hier etwas angesprochen wird was 1) nichts mit dem Thema zu tun hat und 2) welches mich nicht interessiert?

Da DU scheinbar irgendein problem mit mir hast, solltest du am besten aus diesem Thema hier verschwinden.

Für mich hat sich das Thema jedenfalls erledigt und ich bin raus hier. Kannst mich nun ruhig beleidigen, ich werde es eh nicht lesen. Da bin ich lieber auf http://www.delphipages.com/ ... (damit sage ich indirekt, dass ich auch aus dem Forum verschwinde).

Edit: ich sehe deine Beiträge dank eines Scripts nun nicht mehr.