A Delphi application is never really too big.
However the larger the exe is, the harder it will be to redistribute the file.
Also if the executable is located on a network-disk start-up time may suffer.
A number of factors make the exe grow:
- enabling debug info (will more or less double the exe size).
Disable the inclusion of debug info in the final exe (see screenshot above).
- including bitmaps (in an
imagelist
or likewise component) will also grow the exe substantially.
- including resources (using a custom *.res) file will grow the size.
I would advise against putting resources in a separate dll.
This will complicate your application, whilst not reducing the loading time and distribution issues.
Turning off debug info in production code is a must.
If you have a Delphi-2010 or newer you can choose to include images in the png
format.
This will take up much less space than old-skool bitmaps.
As long as your app is below 30 MB I would not really worry overmuch about the file size though.
Strip RTTI info
David suggests stripping RTTI info (this will disable live-bindings and some other advanced stuff), see: Reduce exe file
According to David it saves about 30% in exe size.
Exe-size will only increase loading time
Far more important is the amount of data your application allocates as storage.
The amount of space you use (or waste) here will have a far greater impact on the performance of your application than the raw exe size.
Strategy or tools to find "non-leak" memory usage problems in Delphi?
A better way to optimize is to make sure you don't leak resources
How to activate ReportMemoryLeaksOnShutdown only in debug mode?
Windows API calls memory leak detection
Use smart datastructures and algorithms
It gets too general to really narrow it down here, but use algorithms with O(slowly increasing) over O(wasteful increase).
Big-O for Eight Year Olds?
And try and limit memory usage by only fetching the data that you need instead of all the data you might need but probably never will.
Delphi data structures
Etc etc.