Jump to content
A.M. Hoornweg

Delphi 11.0 Alexandria produces more compact x64 executables than 10.4.2 Sydney !

Recommended Posts

Posted (edited)

Hello World,

 

I just had a pleasant surprise - when I build a certain x64 project of mine, the executable is noticeably smaller under Delphi 11 Alexandria (6.5 MB) than under Delphi 10.4.2 Sydney (7.3 MB).  Embarcadero must have done some serious optimizations.

(Edit) the project is compiled with {$WEAKLINKRTTI ON}. 

Edited by A.M. Hoornweg
  • Like 5

Share this post


Link to post
Posted (edited)

Same here. 

PyScripter Delphi 10.4: 17,302 KB

PyScripter Delphi 11: 15,523 KB

10% reduction, not bad.

 

Any idea where this is coming from (generics?)  Probably the first Delphi version that produces smaller executables that its predecessor.

Edited by pyscripter
  • Like 5

Share this post


Link to post
Posted (edited)

I have no idea, it could be a lot of things. Maybe there's less inlining? Or are they finally using a more compact format for RTTI info? Or maybe LLVM is involved now?
Whatever it is, I find the reduction in executable size impressive (I'm a sucker for efficiency).

 

I would be interested to know if x86 code has become tighter also?

 

 

Edited by A.M. Hoornweg

Share this post


Link to post
Posted (edited)
28 minutes ago, A.M. Hoornweg said:

I would be interested to know if x86 code has become tighter also?

x86

PyScripter Delphi 10.4: 11,975 KB

PyScripter Delphi 11: 10,326 K

 

14% reduction!!

Edited by pyscripter
  • Like 3

Share this post


Link to post
8 minutes ago, pyscripter said:

Could you please enlighten us as to how this substantial reduction in executable size has been achieved?

Comparing the map files could provide a clue.

  • Like 1

Share this post


Link to post
Posted (edited)

The Jcl project analyzer shows the largest differences in size to be in the following units.  But there are small size reductions in many other units (rtl and mine).

 

Delphi 10.4 Size   Delphi 11 Size2 Diff
Vcl.Themes 292380   Vcl.Themes 215,944 76,436
System.Classes 360524   System.Classes 314,652 45,872
SVG 124584   SVG 87,720 36,864
System.Threading 119156   System.Threading 87,640 31,516
System.Rtti 219480   System.Rtti 191,064 28,416
Edited by pyscripter
  • Like 2

Share this post


Link to post

If many units are significantly smaller, it could indicate less inlining, less RTTI overhead, or a much more clever compiler (which would be a sensation).

 

It would be interesting to do a few benchmarks and compare some generated assembly code.

Share this post


Link to post
13 hours ago, pyscripter said:

And why has not this been advertised?

While it is a nice thing for some, ever since the use of floppy disks for data exchange has dwindled, the broader audience does not really care about exe sizes.

  • Like 2

Share this post


Link to post
45 minutes ago, Sherlock said:

While it is a nice thing for some, ever since the use of floppy disks for data exchange has dwindled, the broader audience does not really care about exe sizes.

If Microsoft used Delphi, Windows would be a petabyte in size.

Share this post


Link to post
4 minutes ago, A.M. Hoornweg said:

If Microsoft used Delphi, Windows would be a petabyte in size.

But you would be in "Delphi Heaven", not "DLL Hell".

  • Like 1
  • Haha 2

Share this post


Link to post
3 minutes ago, A.M. Hoornweg said:

If Microsoft used Delphi, Windows would be a petabyte in size.

That doesn't really say anything. Most of Windows is written in C and asm, so are more fair comparison would be against Turbo Pascal...

Share this post


Link to post

I don't mean to compare Pascal to C. I just mean that Delphi has become less usable for low-level modular stuff because the executable size has become so big. Delphi 2009 was the last compiler that created really compact executables.  

  • Like 1

Share this post


Link to post
19 minutes ago, A.M. Hoornweg said:

Delphi 2009 was the last compiler that created really compact executables.  

I think even back then people were complaining that Delphi exes were too big.

 

It's not that I can't see the beauty of small executables (I envy the size of an exe produced by a C program using only the standard libraries), the size just hasn't been a priority in what I used Delphi for  for a few decades.

  • Like 1

Share this post


Link to post

I am very happy about noticeable changes in the compiler. It means they really still care. It's just not my main concern to save one or two megabytes here or there.

But I do understand folks that really need it, hence the "broader audience" part in my post... some really need small executables. There is a whole Non-VCL movement out there, that denies themselves the VCL for reasons of exe sizes (among other reasons, I am sure). But, they might not profit from these changes...

  • Like 1

Share this post


Link to post
1 hour ago, Sherlock said:

It means they really still care.

Slightly smaller executable files, binary literals, literal separators, support for new asm instructions. I think "care" feels a little strong.

Share this post


Link to post
24 minutes ago, David Heffernan said:

Slightly smaller executable files, binary literals, literal separators, support for new asm instructions. I think "care" feels a little strong. 

Need a hug? 🙂

  • Haha 1

Share this post


Link to post
30 minutes ago, David Heffernan said:

Slightly smaller executable files, binary literals, literal separators, support for new asm instructions. I think "care" feels a little strong.

Come on what about the way they've changed the high dpi support (it's almost working.).

  • Haha 2

Share this post


Link to post
14 minutes ago, Lajos Juhász said:

Come on what about the way they've changed the high dpi support (it's almost working.).

Well, we were talking about compiler changes

Share this post


Link to post

I found Delphi 11 compiler also generates faster code.   

 

By re-run the Delphi test code for calculating 50000 digits of Pi,

https://talk.remobjects.com/t/updated-benchmarking-oxygene-island-versus-delphi-c-c-and-net/19499

 

I found for the same Pi-Calculation code,  Delphi 11

x64 - 31.684 sec, 6.2% speed improvement (over Delphi Rio)

x32 - 33.880 sec,  3.2% speed improvement (over Delphi Rio)

Edited by wuwuxin
  • Like 3

Share this post


Link to post
On 10/8/2021 at 4:50 PM, Anders Melander said:

It's not that I can't see the beauty of small executables (I envy the size of an exe produced by a C program using only the standard libraries), the size just hasn't been a priority in what I used Delphi for  for a few decades.

In the same time even System has much more stuff included than any C runtime. And with modified runtime binaries are really small. Alas, binary size optimizing was never a goal for RTL architects so we have really good stripping linker and such weird decisions as Exception living in Sysutils that adds ~150 kB including whole Unicode plane and base TStream living in Classes that add ~400 kB even if not used at all.

Share this post


Link to post
22 hours ago, wuwuxin said:

I found Delphi 11 compiler also generates faster code.   

 

By re-run the Delphi test code for calculating 50000 digits of Pi,

https://talk.remobjects.com/t/updated-benchmarking-oxygene-island-versus-delphi-c-c-and-net/19499

 

I found for the same Pi-Calculation code,  Delphi 11

x64 - 31.684 sec, 6.2% speed improvement (over Delphi Rio)

x32 - 33.880 sec,  3.2% speed improvement (over Delphi Rio)

Most likely a sampling variation - the majority of time is spent on the div instruction inside the loop in the OneLoop routine and that did not change - and is not optimizable in any way. Quickly looking into the code that clang or gcc produce it looks pretty similar so I assume VC++ does the same.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×