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

[A.M. Hoornweg 144]

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 October 6, 2021 by A.M. Hoornweg

[pyscripter 689]

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 October 6, 2021 by pyscripter

[A.M. Hoornweg 144]

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 October 7, 2021 by A.M. Hoornweg

[pyscripter 689]

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 October 7, 2021 by pyscripter

[pyscripter 689]

@Stefan Glienke 

@Marco Cantu 

@Dmitry Arefiev

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

Edited October 7, 2021 by pyscripter

[Anders Melander 1783]

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.

[pyscripter 689]

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 October 7, 2021 by pyscripter

[A.M. Hoornweg 144]

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.

[Sherlock 663]

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.

[A.M. Hoornweg 144]

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.

[Rollo62 536]

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

[Anders Melander 1783]

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

[A.M. Hoornweg 144]

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.  

[Anders Melander 1783]

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.

[Sherlock 663]

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

[David Heffernan 2345]

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.

[Anders Melander 1783]

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? 🙂

[Lajos Juhász 293]

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

[David Heffernan 2345]

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

[Stefan Glienke 2002]

Most likely this: https://quality.embarcadero.com/browse/RSP-30870

[pyscripter 689]

@Stefan GlienkeI would add more likes if I could.   Not just for this.  Just look at:

https://quality.embarcadero.com/browse/RSP-34681?jql=reporter%3D"Stefan Glienke"

 

Isn't [RSP-34681] Get rid of TListHelper and use strongly typed field (TArray<T> - Embarcadero Technologies also relevant?

[Stefan Glienke 2002]

6 hours ago, pyscripter said:

Isn't [RSP-34681] Get rid of TListHelper and use strongly typed field (TArray<T> - Embarcadero Technologies also relevant?

No, that only affects the ability to properly see the content of the list when debugging

[wuwuxin 28]

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 October 10, 2021 by wuwuxin

[Fr0sT.Brutal 900]

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.

[Stefan Glienke 2002]

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.