Search code examples
delphiexedelphi-10-seattle

Is there any risk in having an exe larger than 100MB built with Delphi?

My Delphi win32 VCL Application is deployed as a single big exe. The application is a Client Server application with a Fat Client that connects to SQL Server.

This is convenient (it is enough to update one file in a shared folder and the application is updated- of course the DB schema gets updated too).

Since I use many "fat" third party components like ReportBuilder and DevExpress at every release the exe size grows mostly because those components become bigger and bigger.

In the dpr I set these flags to ensure when exe is launched from shared folder or from removable device it is always loaded in memory (and avoid odd connections errors):

{$SetPEFlags IMAGE_FILE_NET_RUN_FROM_SWAP}
{$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP}

If the exe is built with the Release Build Configuration a normal exe usually reduces the size of about 50% (compared to Debug Build Configuration). But since I use EurekaLog, building with Build instead than Debug just slightly reduces the size.

Currently my exe is 115MB (built with "Build" Build configuration and EurekaLog).

Is it ok in anyone experience? Is it there a known limit that is advisable not to exceed?

Here's how the size has grown in recent years:

2014: 76MB

2015: 82MB

2016: 90MB

2017: 97MB

2018: 115MB

Since I recently exceeded the 100MB limit I started to worry.

I know that it is possible to build with runtime packages but my question focuses on keeping the single big exe approach if possible.

I remember cnPack has a Uses Cleaner feature I tried in the past. This could likely help me remove some non used unit and therefore reduce the exe size, but anyway this cannot stop the trend that brought me over 100MB.

Thanks.

Solution

  • I asked EurekaLog and they replied:

    The size of your EXE after EurekaLog processing is mostly determined by the size of your MAP file. Other things that affect the size of the EXE include the EurekaLog options you select, such as memory checks, Senders, JCL support, Etc.

    You can reduce the size of the EXE somewhat by selecting the EL Compression option. Keep in mind that compression can affect startup time, since the debug information needs to be decompressed when you launch the EXE.

    You can further reduce the MAP file size by turning off debug information in parts of your program that you don't need to stack trace after a crash. Large component libraries like DevExpress would be a good start.

    Last, you may have other compiler options like range checking turned on/off in tandem with EurekaLog. Some compiler options can contribute to EXE size.

    You can use our EurekaLog PE Analyzer to view details on debug information size, Compression, Etc.

    So somehow user Ville Krumlinde is right when he says that debug info is the cause. So to answer the question there are no problems in having a big exe, to reduce exe size the Release Build Configuration must be used, to use Eureka Log one should try to reduce he the map file size, in the above quote most hints are there.