Wieviele Zeilen/Zeichen verträgt eine Unit?

[MmVisual]

Es geht mir in der Tat nicht um das sparen dieser paar MB, sondern das Handling der Hilfedateien macht es in einem ZIP (als Container von vielen Dateien) einfacher. Es sind dann alle 100, 200, 500 oder 1000 Dateien drin und man kann das benutzen und nach Dateien drin suchen. In der Programmierung macht es keinen Mehraufwand, egal wie ich die Hilfe ändere.
Daher ist diese Lösung schlussendlich Zeitsparend, zumal es fertige Komponenten gibt die eine ZIP als Stream bedienen können.

Abgesehen davon habe ich die Funktion der integrierten Programmhilfe schon in mehreren Projekten verwendet, der Aufruf ist nur die Helpcontext Zahl und die kann in jedem beliebigen Objekt in einer Form eingegeben werden.

[Erwin]

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.

Wieso KnowHow? Und wie kommst Du darauf, dass dort bei fpcupdeluxe nicht auch mal Fehler auftreten? Sind die dort etwa unfehlbar? Vielleicht war es damals sogar deren Schuld, vielleicht fehlte zu dem Zeitpunkt, als man Lazarus für das Software-Center eingerichtet hat, diese Datei?

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.

Nun ja, nur weil ich alles in eine Anwendung gepackt wird, kann trotzdem ja was fehlen, wenn man es selber eben vergessen hat. Das stimmt. Aber für mich als Anwender finde ich es klarer wenn alles in einer Anwendung ist. Wenn nämlich mal was fehlt, fängt man ja meist an, zu suchen, was fehlt. Man fragt sich, ob was beim Installieren/Kopieren falsch lieft. etc. Wo man die fehlende Datei herbekommen kann. etc. Oft führte so was zur langer Suche ohne Ergebnis. Wenn es nur eine Datei ist, dann geht oder es geht nicht. Und selber finde ich so was eben einfach super, wenn man als Anwender nur auf eine Datei achten muss, und nicht mit mehren sich herum plagen muss.

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.

Software-Firmen haben früher (und machen das vermutlich auch Heute noch) Spiele hergestellt, die zu deren Entwicklungszeit nicht am Rechner liefen. Sie erklärten dann, bis das Spiel in paar Jahren fertig ist, gibt es dann Rechner, worauf das Spiel dann laufen kann. Da wird man gegenseitig angeheizt, zum immer mehr, mehr und mehr. Vor allem aber achten die nicht darauf, dass dadurch der Bedarf immer größer wird, wodurch die Programme schnell (und unnötig) sehr groß werden können.
Viel Speicher führt oft auch dazu, diesen möglichst voll zu machen. Weil man hat ja Platz, und wozu hat man so viel Speicherplatz gekauft, wenn dann eh vieles leer ist. Und dies wiederum führt dann auch dazu, dass dieser dann doch schnell voll ist, vor allem mit Müll (bzw. Filmen, Programmen etc. die dem jeweiligem Nutzer nicht wirklich interessieren, aber man hat ja Platz ... gehabt).
Es ist die eine Sache während des Programmierens auch Kommentare mit in die Exe zu packen. Aber in der Endfassung sollte dies und auch alles andere, was es nicht braucht, raus fliegen. So viel Zeit und Arbeit sollte man sich doch machen, damit das Programm kleiner wird, finde ich. Und ich will halt schon vorher darauf achten, alles möglichst klein zu halten, als umgekehrt, alles dann (unbewusst) aufzublähen, um dann verwundert festzustellen, wieso mein Anwendung über mehrere GB groß ist. Das ganze wächst durchaus recht schnell, finde ich.
Und große Programme wirken sich nicht nur auf Speicherplatz aus, sondern wenn man es hin und her schickt auch auf die Übertragungszeit (Internet) oder Kopierzeit (über Kabel) etc. aus.

Ich jedenfalls bewundere Firmen wie FTL, die damals z.B. Sundog auf eine Diskette (max. 720 KB ... Programm selbst war, glaube ich, sogar nur die Hälfte groß) untergebracht haben. Mit gut 1 Dutzend Planeten, mind. 2 mal so viele Städten mit unzähligen Gebäuden (die man auch noch betreten konnte) ... und frage mich: Wie verdammt haben die das gemacht? Würde das Heute eine 'Professionelle' Spiele-Software-Firma machen, wäre es vermutlich 50 GB groß (weil darunter, glaube ich, geht da Heute eh nichts mehr?).

[Warf]

Es geht mir in der Tat nicht um das sparen dieser paar MB, sondern das Handling der Hilfedateien macht es in einem ZIP (als Container von vielen Dateien) einfacher. Es sind dann alle 100, 200, 500 oder 1000 Dateien drin und man kann das benutzen und nach Dateien drin suchen. In der Programmierung macht es keinen Mehraufwand, egal wie ich die Hilfe ändere.
Daher ist diese Lösung schlussendlich Zeitsparend, zumal es fertige Komponenten gibt die eine ZIP als Stream bedienen können.

Ja wie gesagt, dein Beispiel wo du explizit externe Dateien einbindest ist ein sehr Spezieller Fall. Hierbei gings mir nur um wirklich Programmdaten die zur Laufzeit dann in Programmdatenstrukturen wie Arrays, Strings, Record, etc. geladen werden.
Solang man da keinen richtig guten Grund hat die Anderweitig darzustellen, ist eine in-language representation oftmals die mit abstand einfachste Lösung

Viel Speicher führt oft auch dazu, diesen möglichst voll zu machen. Weil man hat ja Platz, und wozu hat man so viel Speicherplatz gekauft, wenn dann eh vieles leer ist. Und dies wiederum führt dann auch dazu, dass dieser dann doch schnell voll ist, vor allem mit Müll (bzw. Filmen, Programmen etc. die dem jeweiligem Nutzer nicht wirklich interessieren, aber man hat ja Platz ... gehabt).

Naja, Speicher wird ja nicht umsonst belegt. Beispiel Spiele, moderne Spiele können z.T. Hunder GB oder Größer sein. Der Grund dafür ist recht einfach, die ganzen Medien (Texturen, Objekte, Musik, etc.) sind recht groß. Diese Spiele erreichen z.T. Photorealistische Grafiken, brauchen dafür aber sehr Hochauflösende Texturen und Objekte, etc. Oftmals haben die Spiele verschiedene Grafikmodi, und benötigen daher die ganzen Medien in doppelt und Dreifacher Ausführung für verschiedene Auflösungstufen etc.

Ein anderes schönes Beispiel ist Executable Größe. 64bit Executables sind auf verschiedenen Betriebsystemen viel Größer als die 32bit Versionen, und das liegt nicht an mehr inhalt. Tatsächlich ist viel Größenunterschied sog. padding, bei dem einfach 0 Bytes eingefügt werden. Der Grund dafür ist damit die verschiedenen Sektoren der Executable memory aligned sind, und die Datei einfacher in den Speicher gemapped werden kann. Das führt dazu das die Dateien um ein Vielfaches Größer sind als notwendig, im Gegenzug ist die Ladezeit vom Betriebsystem um den Prozess zu starten um ein vielfaches kleiner.

Und zu guter Letzt, zwar gilt es oft als Hilfreich Code Informationen wie Debug Symbole und Co nicht in die Release Version zu kompilieren, das kann aber auch nicht nur von Vorteil sein, da Reflection techniken genutzt werden können um informationen über die Ausführung zur ausführung zu bekommen. Beispiel, wenn eine Exception kommt, möchte man evtl den gesammten Aufrufstack loggen damit dieser Fehler gemeldet und rekonstruiert werden kann. Das gesamte Ökosystem von Java basiert darauf das man Praktisch zu jedem Zeitpunkt komplettzugriff auf den Code hat, und egal ob man Java mag oder nicht, ist es doch eindeutig ein sehr großer Teil des Erfolgs der Sprache.

Also klar, wenn jemand seine Programme einfach mit unnötigen Bytes füllt ist das doof, aber da Speicher so eine unfassbar billige resource ist, Entwicklungs und Wartungszeit sowie CPU und Grafikleistung allerdings extrem Teuer sind, hat es einen Grund warum so oft Anwendungen so gigantisch werden.

[Erwin]

Also klar, wenn jemand seine Programme einfach mit unnötigen Bytes füllt ist das doof, aber da Speicher so eine unfassbar billige resource ist, Entwicklungs und Wartungszeit sowie CPU und Grafikleistung allerdings extrem Teuer sind, hat es einen Grund warum so oft Anwendungen so gigantisch werden.

Früher hatte man nur 256 Farben. Ok, das fällt auch mir auf. Aber ca. 65 000 finde ich ausreichend. Von 16 MB ganz zu schweigen. Aber, so mein Eindruck, wollen sich da immer alle gegenseitig übertreffen, so dass ich den Eindruck habe, dass keinem mehr 16 MB Farben ausreicht. Nicht nur von Entwickler zu Entwickler, sondern auch von Spieler zu Spieler. Wenn man Grafiken (und auch Sound) Programmiert, wo vieles dann drin ist, was man eh nicht mehr wahrnehmen kann, weil der Unterschied untereinander (also von Farbton zu Farbton) einfach zu gering ist, dann wird dort meiner Meinung nach viel zu viel Reosurcen verbraucht. Da sehe ich die Quelle des Problems für die Größe der Spiele.

Viele Spiele sind bei mir nicht wegen der Grafik und oder Sound in der Ecke gelandet, sondern diese landeten dann zu über 75 % wegen miesen Gameplay und zu über 20 % wegen Bugs in der Ecke. Überwiegen Spiele, die bis zum Jahr 2000 entwickelt wurden. Also Grafik und Sound hat mich ganz selten gestört, bzw. vom Spielen abgehalten. Das Gameplay war einfach ... mist. Aber Grafik und Sound scheint das zu sein, worauf man sich konzentriert.

Mir fällt auf, wir haben uns schon seit langem vom eigentlichem Thema entfernt. Will mich nicht beklagen, weil auch das andere ist sehr interessant und betrifft auch auf anderen Weg mein Hauptanliegen. Aber wäre doch schön, noch etwas mehr zum eigentlichem Thema zu erfahren.