How can I reduce resources inside my application? I have tried a number of tricks I have reduce and rewritten code, reduce line number, Reduce comments, Compressed the final EXE, but this is not the way I want to go, Improve the variable type cast, Remove ICONs,BMP,JPG, from inside the application I need my applications to be as small as possible on the final EXE and in general resource consumption. Any more ideas, any good articles on this subject Thanks
A:
Use a memory profiler like the one from Red Gate to get a real time view into the run-time memory usage.
David Schmitt
2009-01-06 10:39:25
+9
A:
I would not spend any time removing comments the compiler strips them out anyway
You could reference your images from an external service(eg Amazon S3)
cgreeno
2009-01-06 10:42:07
+2
A:
Is it really worth all this trouble? We are not living in 640 KB memory times anymore.
If you want youre EXE to be smaller then use dynamic linking of packages and libraries. That gives most of the boost. Also put all your resources (images,sounds) into separate DLL. You won't save anything by deleting comments and writing all your code in one long line.
Riho
2009-01-06 10:54:31
Using dlls does only gain you anything if some applications and maybe other libraries of a whole suite of programs all use them. Splitting code and resources from a single executable may have benefits, but size reduction or speed increase are not among them.
mghie
2009-01-06 11:56:22
It all depends on what he actually is trying to achieve. If he wants to let users update the software over internet, then you want to get small EXE file (most often changed) and static content (images, etc.) in separate DLL that doesn't usually need to be changed.
Riho
2009-01-07 09:02:53
+10
A:
What about switching debug information off in the project options:
- no debug info
- no runtime checks
- reduce number of external units uses if possible.
But debug info kan be a major killer.
Gamecat
2009-01-06 10:55:17
+7
A:
Put any images that the program uses more than once into image lists or TGraphic components, and put those into a data module. Link all your components using these glyphs to the image lists. If you use the Object Inspector to add the same glyph to several components you will end up with multiple copies of it, increasing both your loading time and your executable and working set size.
mghie
2009-01-06 10:56:05
+4
A:
Do not create all forms automatically, even though Delphi gives you the option now, and did this unconditionally for new forms in earlier versions. Only create the main form, and use the following (pseudo) code for the showing of modal dialogs:
procedure TMainForm.OptionDialog(Sender: TObject);
var
Dlg: TOptionDialog;
begin
Dlg := TOptionDialog.Create(nil);
try
// prepare dialog
if Dlg.ShowModal = mrOK then begin
// apply changed settings
end;
finally
Dlg.Free;
end;
end;
This will shorten application loading time and reduce your overall resource usage, especially for complex dialogs with many controls.
mghie
2009-01-06 11:05:25
No need for the SELF here since you are managing the destruction yourself. so changing the first code line to read Dlg := TOptionDialog.Create(nil); is a better way to handle this.
skamradt
2009-01-06 14:54:38
It's a matter of preference, no harm is done either way. I can live with the extra microsecond this will cost. And I need to use the parent form as the owner in any case, as I have code in my dialog base class to center it on the parent.
mghie
2009-01-06 15:28:38
Some info about using "nil" instead of "Self":http://delphi.about.com/od/kbcurt/ss/dynamiccreateno.htm
Andreas Hausladen
2009-01-06 19:05:02
@Andreas: I'm not too wild about that article. At least the "Risk of double Free" as explained on page 10 is IMHO completely bogus: If I have a long running method of a Form, an inside it the Form is freed inside of Application.ProcessMessages, then the programmer has much bigger problems than ...
mghie
2009-01-06 20:45:54
the double Free of the dynamically created TTable. All access to the form could then lead to crashes, even when the TTable was created with nil as the owner. It's certainly a bad idea to free any object while executing one of its methods. Apart from "delete this;" as the last line.
mghie
2009-01-06 20:48:27
+4
A:
Drop the VCL and use KOL and MCK: http://kolmck.net/
This is radical and very big change, but will get the exe size down.
Harriv
2009-01-06 11:53:41
I was actually just posting that when you posted it. You can actually dynamically link to the KOL / MCK (it is kind of tricky) and get your EXE down to next to nothing!
Jim McKeeth
2009-01-06 12:05:19
+2
A:
Typically speaking if you want a smaller EXE size then go with an earlier version of Delphi.
Jim McKeeth
2009-01-06 12:04:17
No need to vote this down. It is a very valid answer, even if you can't use this yourself. Inno Setup is still compiled with Delphi 2 and 3, exactly to achieve minimum executable size. We are speaking about several 10 kByte, easily.
mghie
2009-01-06 12:33:42
+1
A:
I always use UPX to compress exe files. It works perfectly, often resulting in a factor 2 compression. And, of course, disable all the debug info will help reduce file size.
birger
2009-01-06 12:27:09
Please also read http://stackoverflow.com/questions/353634/are-there-any-downsides-to-using-upx-to-compress-a-windows-executable
Lars Truijens
2009-01-06 13:25:01
+6
A:
A nice trick to reduce executable size (actually, PE-image size, as this applies to DLL's too), when relocation is not an issue :
Leave the relocation-info out!
In Delphi, you could do it like this :
// Remove relocation table (generates smaller executables) :
// (See http://hallvards.blogspot.com/2006/09/hack12-create-smaller-exe-files.html)
{$SetPEFlags 1} // 1 = Windows.IMAGE_FILE_RELOCS_STRIPPED
Cheers!
PatrickvL
2009-01-06 16:24:55
To combine this with the tip from Jim McKeeth about using an earlier Delphi version: If your Delphi version doesn't support $SetPEFlags then use StripReloc.exe by Jordan Russell on the final executable. See on his website http://jrsoftware.org/striprlc.php.
mghie
2009-01-11 09:53:08
+3
A:
Measure first, THEN optimise. How big is your application, and how big would you like it to be?
Are you concerned about...
The size of the application .EXE file on disk? Then...
- Build with runtime packages on. You'll get a tiny .EXE, but will need to distribute .bpls as well.
The RAM memory used by the application? Then...
- Build with runtime packages off - the linker will omit most unused parts of packages.
The size of the application installer? Then...
- Build with runtime packages off
- Use Inno Setup
- Most of the suggestions above?
The size of the application PLUS PACKAGES/DLLS after installation? Then...
- Build with runtime packages off, and use UPX
Roddy
2009-01-06 16:37:55
+2
A:
Project -> Options -> Compiler:
===============================
Optimization ON
Debug Information OFF
Local Symbols OFF
Reference Info OFF
Use debug DCUs OFF
Project -> Options -> Packages:
===============================
Build with runtime packages ON (but you will have to distribute your BPLs!)
Note to non-delphi folks:
a BPL is just a DLL, but with magic Delphi dust to make it easier to use.
JosephStyons
2009-01-06 16:49:30
Debug Information OFFLocal Symbols OFFReference Info OFFThese three have no impact on the EXE/DLL/BPL. The information is stored in the *.dcu and *.dcp files only.
Andreas Hausladen
2009-01-06 18:57:27
A:
UPX and ASPack will create a lot of trouble because antivirus false positive alarms. Kaspersky does that a lot!
Altar
2010-09-26 18:38:24