Effizientes speichern von Daten (25500 Objekte in einer Liste?)

Hallo,

ich sitze vor einer neuen, etwas seltsamen Aufgabe.
Ich habe hier ein riesiges C++ Programm mit ca. 17000 Files.
Grob halbiert also ungefähr 8500 *.cpp Files.

Jetzt soll ein C# Programm her was die cpp Files eine nach der anderen einliest und zu jeder Funktion/Methode innerhalb der File verschiedene Werte speichert.

Der erste gedankliche Ansatz war natürlich ich erstelle eine Klasse für die Funktionen und kann dann für jede Funktion ein Objekt erzeugen mit seinen Daten.
Bei den Daten handelt es sich im Moment lediglich um 2 Strings, 2 Ints und 1 Bool.
Also nur 5 get/set Methoden.

Die Frage die sich mir jetzt mangels Erfahrung stellt ist, 8500 Files wovon jede meinetwegen nur 3 Funktionen hat (es sind mit Sicherheit mehr) würde am Ende bedeuten 25500 Objekte in einer Liste...

Das ist doch ziemlich speicherintensiv oder ? Gibt es irgendeine sinnvollere Methode das zu speichern oder mach ich mir da jetzt unnötig Gedanken ? Ich hab in solchen Größenordnungen noch nie gearbeitet, mir fehlt leider jedes Gefühl dafür ab wann das Ganze sinnfrei wird.

Grüße

PS: Das schreiben in eine *.txt File wäre vlt eine Idee aber da ist die Weiterverarbeitung ja wieder aufwendiger.

Naja 25500 Objekte mit den paar Properties ist kein Thema für den Speicher - und wenn dann ist Windows so intelligent und lagert das aus.

Ich hab einige Sitationen, in denen ich bestimmt > 1 Mio Objekte im Speicher hab; aber das ist alles kein Thema für die Performance.

Würde mir da erst Gedanken machen, wenns wirklich nen Problem geben sollte.
Alles andere zählt zu "premature optimization is the root of all evil".

Danke für die Antwort, dann sollte das funktionieren und ich werde es so lösen.

Würde mir da erst Gedanken machen, wenns wirklich nen Problem geben sollte.
Alles andere zählt zu "premature optimization is the root of all evil".

Das find ich jetzt aber nicht. Weil programmiere ich das jetzt zBsp mit den Objekten aus und am Ende stellt sich raus dass das doch zu langsam ist und es muss dann doch eine Datenbank oder andere Lösug her, geht das "Umgeschreibe" der Anwendung los. Da informiert man sich doch schon beim Design ob das ganze überhaupt praxis-orientiert ist 😃

Hallo scrabbl,

der Speicherplatz ist sicher nicht das Problem. Das kann man ja leicht ausrechnen, dass da noch quasi nichts zusammenkommt.

Es könnte schon eher ein Problem sein, wenn du die Liste bei jeder neuen Funktion durchsuchst, ob sie schon vorhanden ist. Dann wäre es sinnvoll, die Funktionsnamen nicht in der Liste, sondern in einem Dictionary<> zu speichern.

Es kommt also eher darauf an, welche Operationen du wie oft ausführst. Welche Operation auf welcher Collection welchen Aufwand verursachen, steht in der MSDN Doku bei den einzelnen Methoden.

Siehe auch [Übersicht] Collections (Auflistungen) ab .NET Framework 2.0.

Da informiert man sich doch schon beim Design ob das ganze überhaupt praxis-orientiert ist

Was aber auch Zeit kostet, insbesondere wenn man es an allen möglichen Ecken und Enden unnötig tut. Man sollte also wenigstens Anhaltspunkte dafür haben, dass ein Engpass tatsächlich zu erwarten ist.

herbivore

Danke auch für deine Antwort.
Ja es wird auf ein Dictionary rauslaufen, da bei der späteren Weiterverarbeitung entsprechende Objekte am schnellsten gefunden werden können und ein eindeutiger Schlüssel vorhanden ist.

Da informiert man sich doch schon beim Design ob das ganze überhaupt praxis-orientiert ist
Was aber auch Zeit kostet, insbesondere wenn man es an allen möglichen Ecken und Enden unnötig tut. Man sollte also wenigstens Anhaltspunkte dafür haben, dass ein Engpass tatsächlich zu erwarten ist.

Da hast du natürlich recht.
Es ging mir ja auch nicht um mögliche "Optimierungen" sondern darum das ich mir unsicher war ob das ganze so überhaupt sinnvoll realisiert werden kann. Und das wollte ich dann doch vorher klären 😃

Grüße

Um zu prüfen ob es geht, könntest du eine Spike-Solution anlegen und die Operationen auf Dummy-Daten ausführen, die du für die Produktivlösung lokalisiert hast.
Dann kannst du sehen, ob die Arbeit mit den Operationen und der Größe problematisch ist.

Überlege dir wie viel Platz pro Eintag gebraucht wird. Wenn man von grob 1kb/pro Objekt ausgeht, was vermutlich vollkommen übertrieben ist landest du bei schlappen 24mb. also noch lange nicht besorgniserregend