Recent

Author Topic: How to reduce EXE program size?  (Read 19071 times)

Dodfr

  • New member
  • *
  • Posts: 6
Re: How to reduce EXE program size?
« Reply #60 on: June 30, 2021, 04:27:01 pm »
KOL is not Delphi only. It works with our favorite compiler as well...
https://wiki.freepascal.org/KOL

Excellent :-) I have an old Ressource Meter for years made with on D7+KOL and I wanted to make it x64



marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9701
  • FPC developer.
Re: How to reduce EXE program size?
« Reply #61 on: June 30, 2021, 04:48:48 pm »
64-bit is always larger, so if you want to keep it small....

Dodfr

  • New member
  • *
  • Posts: 6
Re: How to reduce EXE program size?
« Reply #62 on: June 30, 2021, 06:17:41 pm »
64-bit is always larger, so if you want to keep it small....

The thing is that I also check for some infos of running process it is to retrieve start command line that I can get from 32bits to 32bits processes but not from 32bits to 64bits (the ressource meter also show Top most CPU process Top RAM Top DiskActivity but for this I use Perfomance Counters) original size is 450KB and once compressed with UPX it is 150KB standalone fully portable exe zero install zero DLL.

Seenkao

  • Sr. Member
  • ****
  • Posts: 261
Re: How to reduce EXE program size?
« Reply #63 on: June 30, 2021, 11:11:04 pm »
Для уменьшения исполняемого файла надо перебрать файл system.pp для данной системы и исключить всё что вам не нужно или "минимизировать" код. Это было уже сделано Владимиром Кладовым, но на ассемблере для Delphi и для 32-х битной системы. Возможно тот код можно использовать для FPC/Lazarus (что-то уже переводилось для FPC/Lazarus).

Всю информацию и связаться с Владимиром Кладовым вы можете на сайте http://f0460945.xsph.ru/rindex.htm

google translate:
To reduce the executable file, you need to iterate over the system.pp file for the given system and exclude everything that you do not need or "minify" the code. This was already done by Vladimir Kladov, but in assembler for Delphi and for a 32-bit system. Maybe that code can be used for FPC/Lazarus (something has already been translated for FPC/Lazarus).

All information and contact with Vladimir Kladov you can visit the website http://f0460945.xsph.ru/rindex.htm

WackaMold

  • Newbie
  • Posts: 4
Re: How to reduce EXE program size?
« Reply #64 on: July 19, 2021, 10:12:01 pm »
UPX Exe-packer from https://upx.github.io shrinks the empty program after compiling+linking from 44,032 bytes to 19,968 ... and a demo GUI About program from 2,853,376 bytes to 826,880 (68% shrinkage).

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9701
  • FPC developer.
Re: How to reduce EXE program size?
« Reply #65 on: July 19, 2021, 10:13:49 pm »
UPX Exe-packer from https://upx.github.io shrinks the empty program after compiling+linking from 44,032 bytes to 19,968 ... and a demo GUI About program from 2,853,376 bytes to 826,880 (68% shrinkage).

UPX is known, the FPC distribution even used to use it, but it was removed because it caused more problems (read: antivirus problems) than it solved.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 737
Re: How to reduce EXE program size?
« Reply #66 on: October 26, 2021, 10:59:08 am »
Sorry for necroposting, but, I guess, my post will be useful. I don't see, that anybody has mentioned obvious way to decrease EXE size - runtime packages. It's one of two biggest EXE size offenders. Second is RTTI. Real reason, why C++ programs are so small - they use C++ Runtime Redist. I.e. all that msvcrt.dll stuff. Problem with Pascal - is that all that stuff is always built-in into every EXE and DLL, it produces. But! Funny thing, but Delphi allows this too. And this mechanism is called "Runtime packages". Problem is - Delphi Redist isn't as well-known, as C++ Redist. Not many developers know about it and provide it with their applications. They usually prefer to provide bpls themselves and this kills whole advantage of using runtime packages. Because if they're would be installed system-wide, they would be shared between all apps.

For example for my app (total size, including plug-ins):
Built-in 32bit: 9.75Mb
Built-in 64bit: 15.00Mb
Runtime 32bit: 4.77Mb (-51%) + 6.00Mb runtime
Runtime 64bit: 7.16Mb (-53%) + 8.62Mb runtime

But size change per plug-in is more dramatic:
Built-in 32bit: ~375Kb
Built-in 64bit: ~610Kb
Runtime 32bit: ~75Kb (-80%)
Runtime 64bit: ~130Kb (-79%)

So, more plug-ins - bigger advantage.
« Last Edit: October 26, 2021, 11:24:57 am by Mr.Madguy »
24.11.2021 - DynamicData 4.0 runtime is overhauled to improve scalability.
My project still requires full Delphi 2009 support to be ported to Lazarus.
It's time to finally do it, because Delphi 2009 is 12 years old.

Alextp

  • Hero Member
  • *****
  • Posts: 1483
    • UVviewsoft
Re: How to reduce EXE program size?
« Reply #67 on: October 26, 2021, 11:33:36 am »
Runtime packages are ok only on Windows, imagine what problems will have users on Unixes.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 737
Re: How to reduce EXE program size?
« Reply #68 on: October 26, 2021, 11:53:25 am »
Runtime packages are ok only on Windows, imagine what problems will have users on Unixes.
I don't think so. Unixes also have something like libc.so. It's just RTL, that is separated to DLL. We can do the same with .so libraries too. For example compile RTL into something like libfpcrtl.so and distribute all this libraries as separate LazRTL package.
24.11.2021 - DynamicData 4.0 runtime is overhauled to improve scalability.
My project still requires full Delphi 2009 support to be ported to Lazarus.
It's time to finally do it, because Delphi 2009 is 12 years old.

Handoko

  • Hero Member
  • *****
  • Posts: 4383
  • My goal: build my own game engine using Lazarus
Re: How to reduce EXE program size?
« Reply #69 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.
« Last Edit: October 26, 2021, 12:09:39 pm by Handoko »

jamestien

  • New Member
  • *
  • Posts: 35
Re: How to reduce EXE program size?
« Reply #70 on: October 26, 2021, 12:09:30 pm »
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...
Lazarus 2.0.12/2.2.0RC1 (Win10, Xubuntu, Pop!Os)

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 737
Re: How to reduce EXE program size?
« Reply #71 on: October 26, 2021, 05:16:11 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.
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.
24.11.2021 - DynamicData 4.0 runtime is overhauled to improve scalability.
My project still requires full Delphi 2009 support to be ported to Lazarus.
It's time to finally do it, because Delphi 2009 is 12 years old.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9701
  • FPC developer.
Re: How to reduce EXE program size?
« Reply #72 on: October 26, 2021, 11:06:49 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.
This problem is fixed in Snap and Flatpack.

"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.

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.

« Last Edit: October 27, 2021, 11:10:33 am by marcov »

PascalDragon

  • Hero Member
  • *****
  • Posts: 3515
  • Compiler Developer
Re: How to reduce EXE program size?
« Reply #73 on: October 27, 2021, 10:37:28 am »
Runtime packages are ok only on Windows, imagine what problems will have users on Unixes.

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

  • Administrator
  • Hero Member
  • *
  • Posts: 9701
  • FPC developer.
Re: How to reduce EXE program size?
« Reply #74 on: October 27, 2021, 11:12:05 am »
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)

 

TinyPortal © 2005-2018