Forum > Windows

How to reduce EXE program size?

<< < (15/16) > >>

jamestien:
You are talk about EXE, so I assume that you are on Windows machine.
If you want to get minimal EXE size of your program regardless of all the hassles, then you could just code your program using pure Windows API call like C++ style and handle all the window messages in your main program loop.
 
I used to do this before when I was using Delphi 3 & 7SE to get smallest & fastest program possible. but... man, for all the benefit of those component goodies today, I found it is just impossible to write a program without unnecessary package compiled into EXE. Just live with it...

Mr.Madguy:

--- Quote from: Handoko on October 26, 2021, 12:08:00 pm ---I am no sure but I think Linuxes are not good in handling shared libraries. Many Linux programs (GIMP, Blender3D, OpenShot, etc) I downloaded couldn't start just because library version issue. I learned from mistakes, always install the program from Software Center or correct repository, or use the version that match my Linux version.

--- End quote ---
This problem is fixed in Snap and Flatpack. Even if distributing packages with main application partially kills all benefits, unless your program has lots of plug-ins. But overall it's not problem with concept itself - it's problem with it's implementation in Linux.

marcov:

--- Quote from: Mr.Madguy on October 26, 2021, 05:16:11 pm ---
--- Quote from: Handoko on October 26, 2021, 12:08:00 pm ---I am no sure but I think Linuxes are not good in handling shared libraries. Many Linux programs (GIMP, Blender3D, OpenShot, etc) I downloaded couldn't start just because library version issue. I learned from mistakes, always install the program from Software Center or correct repository, or use the version that match my Linux version.

--- End quote ---
This problem is fixed in Snap and Flatpack.

--- End quote ---

"Fix" is a bit too big a word for those.  Their workaround is pretty much making copies of it in specific containers, is like saying Windows doesn't have DLL hell, because you can place the copies of all dlls in the same directory as the each app. 

Otherwise the whole file size (and memory!)  sharing bit goes out of the window.

I also think the Delphi package system's goal is primarily dynamic loading of code (iow plugins) and using it quite transparently and easy.

There are however also downsides:

* EXE and packages are larger than just the same packages statically linked into the EXE itself. For small programs even significantly so. So you need an average reuse >1 to break even. If you finely divide the packages up into a lot of smaller packages the overhead is lower for small programs, but larger for bigger programs.
* Some people point out that dynamic linking with massive amount of symbols exported and imported is noticeably slower to startup. This is mostly based on the much faster startup time of bare bones installed D7. It could be the packages initialization more than the dynamic loading aspect though. OTOH KDE also suffered from this on *nix in the past, resorting to a "prelink" scheme, so it is probably a real thing.
* Besides that there are also extra indirection costs to access global
identifiers in packages. Afaik the RTL already got some of those in preparation of packages
--- Quote ---Even if distributing packages with main application partially kills all benefits, unless your program has lots of plug-ins. But overall it's not problem with concept itself - it's problem with it's implementation in Linux.

--- End quote ---

Yes, plugins' as in functionality, (not size savings) are the primary goal of packages I think.

As for the Linux problem, it is bigger. Linux simply doesn't value binary interfaces at all beyond the current distribution version iteration. And for non core packages often not even that.

PascalDragon:

--- Quote from: Alextp on October 26, 2021, 11:33:36 am ---Runtime packages are ok only on Windows, imagine what problems will have users on Unixes.

--- End quote ---

This won't be a problem, cause like with all good *nix citizens the runtime package libraries will be versioned:


* librtl.3.2.0.so
* librtl.3.2.2.so
* librtl.objpas.3.2.0.so
* librtl.objpas.3.2.2.so
* etc.
Using dynamic packages at compile time is in principle already possible for the Windows targets (excluding WinCE), the macOS targets as well as x86_64-linux (for all of them it's disabled inside the compiler and there's also the fact that we don't yet have a way to generate packages from fpmake).

marcov:
I revised my post a bit after reading Pascaldragon's, which reminded me that the exact package division in Delphi is not guaranteed within a future FPC/Lazarus package system.

Finer divided packages reduce overhead for programs that only use a few, but increase overhead for larger ones (e.g. lazarus LCL programs)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version