Wieviele Zeilen/Zeichen verträgt eine Unit?

[Erwin]

Ja, irgendwo teils blöde Frage bzw. eine Art Panik Frage.

Die Sache ist die: Habe vor Karten mit Array zu erstellen, die eventuell (eventuell weil zwischen Planen (Theorie) und Umsetzen (Praxis), ... ist hat dann doch ein großer Unterschied) bis zu 1 000 * 1 000 groß wird? Und das nicht nur eine?
Zu Testzwecken (Anwendungsgröße und Speicherbedarf) habe ich dann mal mit einer einfachen Zahl ein dementsprechend großes Array in die Unit geschrieben. Pro Zeile 102 Zeichen, und ... 20 000 Zeilen. Letztendlich, weil ich gleich 3 getestet habe, waren es über 60 000 Zeilen!!
Nun habe ich bei Schreibprogrammen oft erlebt, dass ab 100 Seiten (ca. 800 Zeilen??) manches nicht mehr so richtig funktioniert.

Wie ist das bei Lazarus/FPC? Also das mit den 60 000 Zielen (mind. 600 000 Zeichen!!) hat geklappt. Aber ich frage mich dennoch, ist so was ratsam, oder eben egal? Und wo liegt die Grenze? Ab wann sollte man dann nichts mehr in die Unit schreiben?

Und was wäre besser? Eine Uni mit eventuell 600 000 Zeilen, oder lieber über 100 Units aber dafür mit maximal 21 000 Zeilen?

Und wie sieht es mit den Zeichen pro Zeile aus? Ist das egal? Könnte ich auch Theoretisch 2000 Zeichen pro Zeile machen, und somit auf 1000 Zeilen für so ein großes Array es beschränken?

Ach ja, was den Test betrifft, für Jene die es interessiert, wo ich es schon erwähnt habe und die Daten habe ... .
Habe also eine Array mit 1 000 000 Einträge in die Unit gepackt.
Als Integer (das Array) ist dadurch die Fertige Anwendung um 4 MB und 300-400 Byte angewachsen. Als Byte nur um 1 MB und 300-400 Byte. String habe ich nicht getestet, weil ich dies vermutlich auch nicht brauchen werde.
Bei der Ausführung selbst (also wenn das Programm läuft) schien dies keinen zusätzlichen Arbeitsspeicher zu benötigen: war immer so zwischen 27,0 und 27,4 MiB.

PS: Und ja, unwahrscheinlich, dass ich mit meinen Ehrgeizigem Projekt je fertig werde. Muss man mich also nicht extra drauf hinweisen. Aber in dem Fall werde ich dafür dann bis zum Lebensende Beschäftigt sein. Und will es einfach halt versuchen.

Edit: Danke, Gruß, Erwin.

[theo]

Verstehe nicht ganz. Du willst die ganzen Daten im Quelltext ablegen?
Warum lädst du nicht einfach von einer Datei? CSV würde reichen.

[Mathias]

Wie ist das bei Lazarus/FPC? Also das mit den 60 000 Zielen (mind. 600 000 Zeichen!!) hat geklappt. Aber ich frage mich dennoch, ist so was ratsam, oder eben egal? Und wo liegt die Grenze? Ab wann sollte man dann nichts mehr in die Unit schreiben?

Ich habe auch schon probiert den FPC-Compiler ans Limit zu treiben.
Einzig was ich da entdeckt habe, der C/C++ -Compiler verträgt da mehr,
Ich hatte mal versucht zig 1000x Writeln zu schreiben, aber FPC hatte gleich mal schlapp gemacht.

Wie Theo schon sagt, deine Daten in eine externe Datei auslagern.

[Warf]

Ich glaube auf Windows ist der fpc nach wie vor eine 32 Bit Anwendung, also bist du da mit 3GB RAM Nutzung limitiert. In wie weit das auf unit Größe sich auswirkt kommt auf die unit an (so ist z.b. komplett egal wie viele Leerzeichen oder Kommentare du drin hast)

Ich habe für meine Gold Parser Engine einen Code Generator in meiner VSCode Extension gebaut: https://marketplace.visualstudio.com/it ... rser-tools

Damit können Parser für komplexe Sprachen leicht Zehntausende Zeilen code generieren, funktioniert aber alles wunderbar

[corpsman]

Also ich hab immer wieder Probleme wenn eine einzelne Zeile mehr aus 1024 Zeichen hat. Das kann aber auch am Code Formater meiner Wahl liegen.

Generell kann ich mich aber nur meinen Vorrednern anschließen. Daten sollten nicht in den Source, lege deine Daten in extra Dateien ab. In einem für dich praktischen format und lade sie von da, so lange der einzelne String dann kleiner 2^32Byte also unter ca 3.5GB ist solltest in keine Schwierigkeiten laufen.

[MmVisual]

Zu erst einmal 60000 Codezeilen in einer Unit sind überhaupt kein Problem. Meine Main Unit von meiner Software hat bis heute 73307 Codezeilen.

Abgesehen davon ein Array in Quellcode zu schreiben um es anschließend zu compillieren ist irgendwie unpraktisch.
Mache doch lieber das Array in eine gesonderte Datei, direkt als Binärformat. Anschließend erzeuge aus dieser Datei eine Ressource (lazres.exe ist dein Freund) und binde diese Ressource in deine EXE ein, damit sind diese Daten direkt in der EXE mit verlinkt. Mit dem Befehl TLazarusResourceStream (Noch so ein Freund) kannst du die Daten aus der Ressource in einen TStream laden und damit ein Array direkt füllen.

[Erwin]

Verstehe nicht ganz. Du willst die ganzen Daten im Quelltext ablegen?
Warum lädst du nicht einfach von einer Datei? CSV würde reichen.

Aus dem selben Grund, weshalb ich auch die Grafiken nicht Extern Nachladen will: Damit alles in einer Datei/Anwendung ist. Ich persönliche finde es super, dass FPC/Lazaraus nach dem Kompilieren aus allen dann eine Datei/Anwendung macht. Das eben ein fertiges Programm nur eine Datei ist, und man sich keine Sorgen machen muss, ob man alle Dateien zu nutzen zusammen hat. Bin da über andere Sprachen gestolpert, wo es dann mehre Dateien waren, die dann auch ein anderen Anwender alles erst mal installieren muss.
Leider kann man scheinbar nur Bilder aus der Resource so ohne weiteres Nachladen.
Externe Daten/Dateien gehen halt manchmal gerne verloren, und auch sonst muss man dann immer wieder überprüfen, ob alle Dateien da sind und auch damit herum hantieren.

[wp_xyz]

Aber bitte, du schreibst doch auch dein Programm nicht in einer einzigen Datei. Verschiedene Dateien sind das allererste Mittel, um den Überblick zu bewahren. Warum bindest du die Daten-Dateien nicht als Resource in das ausführbare Programm ein? Das sind ein paar Programmzeilen.

[theo]

Leider kann man scheinbar nur Bilder aus der Resource so ohne weiteres Nachladen.

Mit TResourceStream kannst du alles laden.

Code: Alles auswählen

var RS: TResourceStream;
begin
  RS:=TResourceStream.Create(Hinstance,'TESTTEXT',RT_RCDATA);
  RS.Position:=0;
  Memo1.Lines.LoadFromStream(RS);
  RS.free;
end;   

[Warf]

Abgesehen davon ein Array in Quellcode zu schreiben um es anschließend zu compillieren ist irgendwie unpraktisch.
Mache doch lieber das Array in eine gesonderte Datei, direkt als Binärformat. Anschließend erzeuge aus dieser Datei eine Ressource (lazres.exe ist dein Freund) und binde diese Ressource in deine EXE ein, damit sind diese Daten direkt in der EXE mit verlinkt. Mit dem Befehl TLazarusResourceStream (Noch so ein Freund) kannst du die Daten aus der Ressource in einen TStream laden und damit ein Array direkt füllen.

Lazres fügt resourcen auch nur als binary String konstanten im Quellcode hinzu (das {$I XXX.lrs} fügt die resourcen einfach als Pascal Code konstanten zur aktuellen unit hinzu).

Was du also vorschlägst ist die Daten zu nehmen, zu konvertieren, sie dann als ein großer String in den Quellcode zu packen, damit das Programm sie dann zur Laufzeit wieder rausholen und zurück konvertieren kann.
Da scheint mir ein Array ohne den ganzen Hick Hack doch sinniger zu sein.

[MmVisual]

Was du also vorschlägst ist die Daten zu nehmen, zu konvertieren, sie dann als ein großer String in den Quellcode zu packen, damit das Programm sie dann zur Laufzeit wieder rausholen und zurück konvertieren kann.
Da scheint mir ein Array ohne den ganzen Hick Hack doch sinniger zu sein.

Nein das stimmt so nicht. Man kann jede Binärdatei (z.B. JPG Datei) als Ressource wandeln und diese ist dann nicht als Text in der EXE verressourct sondern in dem binären format, welches man auch direkt (im Beispiel einer JPG Datei) wieder im Bild als LoadFromStream laden kann. Da wird innerhalb der EXE nichts mit String zurück konvertiert. Es ist auch nicht umständlich sondern supereinfach.

Ich habe mit einer ähnlichen Methode die komplette Hilfe mit in der EXE drin:
- HTML Dateien und Grafiken
- Gezippt
- Als Ressource gewandelt
- in der EXE wird das ZIP im MemoryStream gehalten und in einem HTML Viewer Element angezeigt.
- Bei Bilder laden oder Links Klick entsprechend in der MemoryStream-ZIP die Dateien geladen
Die Hilfe als ZIP hat ca. 3MB, die gewandelte LRS Datei ca. 11MB. Ich gehe doch davon aus dass Lazarus beim Linken nicht die LRS Datei einfach so als Text mit linkt sondern weiß dass es Binärdaten sind und entsprechend nur 3MB Platz benötigt. Oder sehe ich das falsch?

EDIT: Gerade getestet, wenn ich die ZIP auf nur 1kb kleiner mache, dann ist die EXE auch 3MB kleiner und nicht 11MB wie die LRS Datei groß ist. Somit die Binärdaten werden auch wirklich Binär in der EXE gelinkt und nicht als Text-Ressource.

[charlytango]

Zu erst einmal 60000 Codezeilen in einer Unit sind überhaupt kein Problem. Meine Main Unit von meiner Software hat bis heute 73307 Codezeilen.

Bin irgendwie etwas fassungslos. Hab ich über die Jahre ein falsches Modell verfolgt?
Selbst Projekte im Umfang mehrerer Mannjahre hatten nur einige 1000d Codezeilen, die dazu noch im wesentlichen nur aus GUI und Menüaufrufen bestanden.

60k und mehr Codezeilen in einer unit würde ich nicht warten wollen. Alleine so ein Konstrukt in einem Editor zu öffnen schreckt mich ab.
Bei einem derartigen Mengengerüst das dann nur Daten enthält denke ich in erster Linie an Datendateien oder Datenbanken.

Aus dem selben Grund, weshalb ich auch die Grafiken nicht Extern Nachladen will: Damit alles in einer Datei/Anwendung ist.

Das ist eine charmante Idee. Doch monolithische Ansätze haben ebenso ihre Downside.

Bin da über andere Sprachen gestolpert, wo es dann mehre Dateien waren, die dann auch ein anderen Anwender alles erst mal installieren muss.

Installieren? Also "richtiges" installieren (damit meine ich eine Programminstallation die sich eben ins Betriebssystem eingräbt) habe ich nie gemacht. Meine Applikationen waren und sind immer "portabel", also auf ein Verzeichnis beschränkt.
Da ist die "Installation" nur ein simpler Kopiervorgang oder ein auspacken aus dem ZIP. Das gestalte ich dann immer so komplex dass notfalls auch die Sekretärin die neue Version kopieren kann wenn RemoteAccess mal wieder streikt. Die Edelvariante ist ein simples Installationsprogramm.

Externe Daten/Dateien gehen halt manchmal gerne verloren, und auch sonst muss man dann immer wieder überprüfen, ob alle Dateien da sind und auch damit herum hantieren

Kann mir gerade nicht vorstellen wie Dateien "verloren" gehen sollen? Indem die Anwender sie löschen? oder der Entwickler sie im System "verliert"?
Und die Überprüfung bleibt einem auch mit der Ressourcenvariante wohl nicht erspart.

Just my 2 cents

[Erwin]

Danke Theo. Habe mal nach gesehen: Geht auch mit StringGrid. Jedenfalls ist da ein vergleichbare Prozedure vorhanden. Sogar für/als CSVFile.

Zu erst einmal 60000 Codezeilen in einer Unit sind überhaupt kein Problem. Meine Main Unit von meiner Software hat bis heute 73307 Codezeilen.

Kein Problem? Schön zu höre ... lesen. Danke.

Was du also vorschlägst ist die Daten zu nehmen, zu konvertieren, sie dann als ein großer String in den Quellcode zu packen, damit das Programm sie dann zur Laufzeit wieder rausholen und zurück konvertieren kann.
Da scheint mir ein Array ohne den ganzen Hick Hack doch sinniger zu sein.

Ja, das sehe ich eben genau so. Zu mal ein Array im Unit/Programm nur so viel Platz in der Fertigen Anwendung einnimmt, wie sie halt Daten enthält, plus 300-400 Byte für das Array-Gerüst selbst. Aber es hat keine Auswirkungen auf den Arbeitsspeicher (MiB) im Laufendem Zustand. StringGrid hingegen, wo man die Daten dann rein lädt ... Irgendwas war da was von das doppelte der Größe der Daten selbst.

Außerdem ... oder: Kann man das auch so eine weiteres in ein Array laden statt StringGrid?

Nein das stimmt so nicht. Man kann jede Binärdatei (z.B. JPG Datei) als Ressource wandeln und diese ist dann nicht als Text in der EXE verressourct sondern in dem binären format, welches man auch direkt (im Beispiel einer JPG Datei) wieder im Bild als LoadFromStream laden kann. Da wird innerhalb der EXE nichts mit String zurück konvertiert. Es ist auch nicht umständlich sondern supereinfach.

Supereinfach? Also ich habe die Erfahrung gemacht, dass selbst das Komplizierteste zwar Supereinfach sein kann, nämlich wenn man es schon x-mal gemacht hat, während einfaches einem zum Verzweifeln bringen kann, wenn man sich damit nicht auskennt.
Dafür dass es Super einfach ist, hast Du nicht viel an einfache Codes dazu geschrieben, wie man das anstellen soll. Und Zip? Muss ich das dann vorher alles mit einen Extra Programm zusammen packen? Aber der Teil mit den noch weniger Speicherplatz, also noch kleinerer EXE-Datei hört sich durchaus gut an. Aber werde ich das Konzept/Vorgehensweise auf die schnelle verstehen können? Oder eher daran verzweifeln?

60k und mehr Codezeilen in einer unit würde ich nicht warten wollen. Alleine so ein Konstrukt in einem Editor zu öffnen schreckt mich ab.
Bei einem derartigen Mengengerüst das dann nur Daten enthält denke ich in erster Linie an Datendateien oder Datenbanken.

Ja, Daten. In dem Fall ganz einfache, bzw. überall habe ich eine Zahl 5 drin gehabt. Um das mal zu testen. Aber letztendlich wird auch so was doch teils als Codezeilen gehandhabt.

Installieren? Also "richtiges" installieren (damit meine ich eine Programminstallation die sich eben ins Betriebssystem eingräbt) habe ich nie gemacht. Meine Applikationen waren und sind immer "portabel", also auf ein Verzeichnis beschränkt.

Naja, das ist eh der Horror. Nein, sondern glaube war eher so, dass es eben erst auspackte und mehre Dateien wurden in einem Ordner installiert, aber auch welche, die ich gar nicht programmiert hatte? Aber auch sonst bin ich oft über Sprachen gestolpert, wo nach dem Kompilieren es mehr als nur eine Datei dabei heraus kam, oder wie im Falle von Pyhton damals, der Anwender selbst Pyhton auf seinem Rechner haben musste. So was finde ich (auch für den Anwender) umständlich.

Kann mir gerade nicht vorstellen wie Dateien "verloren" gehen sollen? Indem die Anwender sie löschen? oder der Entwickler sie im System "verliert"?
Und die Überprüfung bleibt einem auch mit der Ressourcenvariante wohl nicht erspart.

Passiert immer wieder. War es mein vorletztes oder noch eins davor BS ... . Jedenfalls habe ich per Software-Center Lazaraus installiert. Lief aber nicht, weil eine Datei fehlte, dich ich per Hand nach installieren musste. Zum Glück fand ich eine wirklich gute 1 zu 1 Beschreibung, wie man das macht. Habe schon paar mal erlebt, dass eine oder gar mehre Dateien fehlten, und deshalb sogar ein gekauftes Spiel nicht lief. Dann hieß es einfach: Datei XYZ fehlt, bitte nachinstallieren. Nur das es leider nicht vorhanden war, und auch sonst nicht wusste, wo ich es herbekommen soll.

[charlytango]

assiert immer wieder. War es mein vorletztes oder noch eins davor BS ... . Jedenfalls habe ich per Software-Center Lazaraus installiert. Lief aber nicht, weil eine Datei fehlte, dich ich per Hand nach installieren musste.

Das gibt es seit CPM-Zeiten. Da hilft nur Erfahrung und KnowHow.
In diesem Fall verlass dich nicht auf das Software-Center sondern nimm fpcupdeluxe. Dann wird Lazarus direkt aus den Sourcen gebaut.

Habe schon paar mal erlebt, dass eine oder gar mehre Dateien fehlten, und deshalb sogar ein gekauftes Spiel nicht lief.

Ja, mag sein. Für mich ist das nur ein Aufruf zu mehr Sorgfalt im eigenen Bereich und nicht dazu irgendwelche Klimmzüge zu machen, die das Gesamtsystem dann noch komplexer machen.
KISS ist eine bewährte Strategie.

[Warf]

Ich habe mit einer ähnlichen Methode die komplette Hilfe mit in der EXE drin:
- HTML Dateien und Grafiken
- Gezippt
- Als Ressource gewandelt
- in der EXE wird das ZIP im MemoryStream gehalten und in einem HTML Viewer Element angezeigt.
- Bei Bilder laden oder Links Klick entsprechend in der MemoryStream-ZIP die Dateien geladen

Was ja was anderes ist als was hier diskutiert wird. Das sind externe Dateien die du mitlieferst, keine Programmdaten die du im Quellcode brauchst.

Deine hilfe Seiten musst du nur entpacken und anzeigen wenn jemand die Hilfe braucht, aber wenn du Daten die für die Funktionalität benötigt werden enthalten sind, müssen die eh zum Programmstart entpackt werden und liegen eh in voller größe im RAM. Noch dazu muss die entpacklogik und die gepackten Resourcen der .exe im RAM abgelegt werden. Tauschst also RAM sowie CPU Leistung (vor allem start up speed) für Plattenspeicher ein. Kein guter Trade-off.

Ich kann gerne auch ein Beispiel für Daten die ich in-code generiere zeigen, wie bereits gesagt meine GOLD engine, kann man einfach in source sachen generieren, das sind dann Tausende Zeilen a'la:

Code: Alles auswählen

    FDFA.AddCharset(TRangeCharset.FromArray(0, [
      CodepointRange(114, 114)
    ]));
    FDFA.AddCharset(TRangeCharset.FromArray(0, [
      CodepointRange(48, 57),
      CodepointRange(65, 90),
      CodepointRange(95, 95),
      CodepointRange(97, 116),
      CodepointRange(118, 122)
    ]));
    FDFA.AddCharset(TRangeCharset.FromArray(0, [
      CodepointRange(117, 117)
    ]));

Natürlich kann die GOLD Engine auch die GOLD binärdateien lesen und parsen. Das benötigt aber die Parsing Unit mit 400 Zeilen Code, sowie einen nicht unerheblichen RAM und CPU Aufwand während den Parsing, da daten zwischen den Datenstrukturen oft hin und herkopiert werden müssen.
Und es gibt wirklich keinen Vorteil, außer ein bisschen Plattenspeicher, den ich daraus bekommen würde.

Die Hilfe als ZIP hat ca. 3MB, die gewandelte LRS Datei ca. 11MB. Ich gehe doch davon aus dass Lazarus beim Linken nicht die LRS Datei einfach so als Text mit linkt sondern weiß dass es Binärdaten sind und entsprechend nur 3MB Platz benötigt. Oder sehe ich das falsch?

Der Aktuelle Preis für SSDs ist 60€/TB, also wenn du 9 MB sparst, wie oben in deinen Zahlen, Sparst du 0,05ct.
Für jede Stunde die ein Programmierer mit 40€/h Gehalt für dieses Build und Entpacksystem gebraucht hat, muss sich deine Software 800 mal verkaufen damit sich das rechnet.
Das muss eine extrem erfolgreiche Software sein damit sich das lohnt.

Und das ist natürlich ne absolute Milchmädchenrechnung, durch den Mehraufwand hat deine Software längere ladezeiten und braucht mehr CPU leistung. Vermutlich ist allein der extra Stromverbrauch von der CPU für das unzippen schon ein Verlustmodell.

Ich verstehe einfach nicht warum so viele Leute so sehr auf die Größe von Executables achten? Plattenspeicher ist so unfassbar billig das jeder extra aufwand um das ganze kleiner zu bekommen, sich durch den erhöten Entwickluings und Wartungsaufwand des Codes, sowie die Performanceinbußen zum lesen, dekomprimieren und parsen es eigentlich extrem selten die Mühe wert machen.