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

Question

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.

Historic

Runtime packages won't change anything. In fact that would just increase the total size. Because the linker would not be able to strip out unused code. Are you suppressing RTTI? Also, why would a 100MB executable be a problem? Do you suffer any actual issues? I don't see why using a tool like Eureka log should impact executable size. Do they pack their map file into the executable? I use madExcept and there the information used to create stack traces is in an external file. – Fritzie

I use UPX as part of my build process, this makes the exe around 25% of the original size. – Rettarettig

#3199976 - take a look at this thread. Short answer, no, there's no problem with a big binary file – Teirtza

How big is the exe-file with Eureka disabled? Eureka docs says "EurekaLog-enabled applications are self-contained. All code and data are injected into executable module, so you don't need any additional files. No DLLs, no .map files, no .tds files". So I suspect a big part of those 100mb are debug info. But in general I don't think it is a problem with big exe-files. – Whoop

UPX probably makes matters worse though. More likely to attract the attention of anti-malware products, and you force the entire executable to be read from disk at startup rather than letting it be paged in on demand. – Fritzie

The DevExpress components have really ballooned in the last few years (it looks like their skinning system is now compiled in even if you don't use it directly.) It's hard to see the exe sizes get so large but it doesn't cause any actual problems (beyond causing our "unoptimized code" spidey senses to tingle.) – Jittery

@DavidHeffernan: I am doing this for 20 years now, never had any problem. I found that keeping specific resources uncompressed makes the AV scanners happy with my executables. – Rettarettig

@who What do you gain? I can't see any benefit at all in UPX. Perhaps it was worthwhile 20 years ago, but even that's questionable. – Fritzie

In Labracca's case his executable would be 25MB opposed to 100MB. why waste diskspace / internet download size? I come from the C64 era where every byte counted... – Rettarettig

That might make sense if we were still in the same era. That said, I'd be looking to what resources are in the form files and/or other resources, and perhaps optimise those, if size is really a concern – Unlearn

A much scarcer resource is memory and up requires more. And for download size, your download will be packed. – Fritzie

@whosrdaddy: You also came from the days of MS-DOS, GW-Basic, and the Yugo, but you've moved beyond those things now. Drives are considerably larger (I carry a 256G thumb drive, and my smart phone has 64GB of main memory and a 256GB Micro-SD card), and most of us are not using dialup any more. :-) – Spore

Agreed on all your comments above. But my question is, why waste space when you don't have to. But can we also agree on the fact that executables produced by modern Delphi's are bloated (and is it reallynecessary)? – Rettarettig

Thanks to all, in fact for download i 7z my files. 100MB was a "scary psychological threshold", so i will not worry.For sure devexpress skins are #1 culprit. Thanks – Historic

About EurekaLog I will investigate wth them directly, what i see is that Release = (Debug - 5MB) if i build with eureka log – Historic

@who for sure delphi executables are bloated – Fritzie

Answer 1

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.

Historic

Simple solution. Switch to madExcept and have better functionality without packing the map file into the excitable. – Fritzie

@DavidHeffernan excitable ? ;-) – Modernism

Answer 2

You can use "Store all names externally" option to offload some debug information to external file, but your executables will no longer be self-contained.

Muenster