Hallo

Welche dieser Komponenten meines DelphiProgramms ,fressen am meisten Speicherpatz? habe schon die SysUtils durch eine IntToStr und StrToInt. prozedur ersetzt ,was der größe entgegenkam. Doch das ist mir def. zu wenig. NONVcl kann ich nicht arbeiten ,da ich späterhin noch einen Skin mir der VCLSkin komponente hinzufügen möchte. Wäre nett wenn mir jemand eine kleine hilfestellung geben könnte. Was ich bisher in erfahrung bringen konnte udn auch weitbekannt ist , ist der einsatz der KOL Lib./Komp.
Dennoch würde ich einfach mal gerne wissen welcher dieser Komponenten/Units aus meiner Uses-liste, die Übeltäter sind und ob es eine möglichkeit gäbe diese zu ersetzen.

Meine Uses:

markieren

Code:

Windows, Messages, Variants,Classes Graphics, Controls, Forms,
  Dialogs, TextFade,TranComp, jpeg, StdCtrls, Buttons, ExtCtrls, acPNG, FMOD, GIFImage;

(Die Textfade, TransComp und FMod bzw. MiniFmod sind nur ein paar KB groß und absolut vertretbar.)Doch wie siehts mir dem rest aus?

MFG
sun

Classes und Forms

Aber vorher: Wie groß ist denn dein Programm momentan? Und: Du findest es jetzt schon groß und willst noch skinnen? Das vergößert die Datei normalerweise noch mehr.

Und wenn du die SysUtils rausnimmst, kann es sein dass eine andere Unit sie wieder einbindet. Dürfte also nicht allzu viel bringen.

Was hast du davon, wenn deine Anwendung ein paar MB kleiner ist?
Nimm .NET, dann ist sie klein ...

Zitat von sun4623:

NONVcl kann ich nicht arbeiten ,da ich späterhin noch einen Skin mir der VCLSkin komponente hinzufügen möchte. Wäre nett wenn mir jemand eine kleine hilfestellung geben könnte....

Dann bleibt dir nur übrig das du möglichst wenige Komponentensammlungen verwendest sondern dich auf eine 2-3 Sammlungen beschränkst und bei GUI-Kompos nur auf 1 setzt. Nichts bläht die App mehr auf wenn du Toolbar von TMS nimmst, Grid von Quantum, Buttons von LMD, ... Damit wird von jeder Sammlung die Basisklassen/Units gebunden.

Zitat von Deep-Sea:

Was hast du davon, wenn deine Anwendung ein paar MB kleiner ist?
Nimm .NET, dann ist sie klein ...

Oder du lagerst den größten Unfug in eine DLL aus und erstellst eine nonVCL + nonRTL Exe die nur noch die DLL-Methoden aufruft ...

Zitat von mleyen:

Zitat von Deep-Sea:

Was hast du davon, wenn deine Anwendung ein paar MB kleiner ist?
Nimm .NET, dann ist sie klein ...

Oder du lagerst den größten Unfug in eine DLL aus und erstellst eine nonVCL + nonRTL Exe die nur noch die DLL-Methoden aufruft ...

Und die zu große Größe der Exe verpufft dann nach /dev/null oder wie?

Zitat von Luckie:

Und die zu große Größe der Exe verpufft dann nach /dev/null oder wie?

Klasse, geich mal probieren... !

Zitat von Bernhard Geyer:

Zitat von sun4623:

NONVcl kann ich nicht arbeiten ,da ich späterhin noch einen Skin mir der VCLSkin komponente hinzufügen möchte. Wäre nett wenn mir jemand eine kleine hilfestellung geben könnte....

Dann bleibt dir nur übrig das du möglichst wenige Komponentensammlungen verwendest sondern dich auf eine 2-3 Sammlungen beschränkst und bei GUI-Kompos nur auf 1 setzt. Nichts bläht die App mehr auf wenn du Toolbar von TMS nimmst, Grid von Quantum, Buttons von LMD, ... Damit wird von jeder Sammlung die Basisklassen/Units gebunden.

Ist dann wohl der beste Weg.


Oder aber man macht sich dann den Skin selbst...

Zitat aus einer bekannten Werbung:

Alles eine Frage der Technik.

Habe es selbst mal versucht. Beispiel: http://www.delphipraxis.net/140888-%...ayerdings.html

oder: siehe Anhang.

Wenn es nur um die Dateigrösse geht, wäre evtl ein Einsatz eines Exe-Packers wie upx zu überprüfen

Wikipedia
UPX Homepage

Zitat von Bernerbaer:

Wenn es nur um die Dateigrösse geht, wäre evtl ein Einsatz eines Exe-Packers wie upx zu überprüfen

Da meckert das Antivirenprogramm aber ständig rum.
Schon mal gefragt: Was bringt es?