I am upgrading my program from win 32 to win 64 using the new Lazarus 1.8. I discovered my program exe size increased from 6M to 9M.

Why?

Dennis

Why?

At least pointer size takes double space, multiply it with every instances 1.5x bigger is not impossible.

Dennis wrote

I am upgrading my program from win 32 to win 64 using the new Lazarus 1.8. I discovered my program exe size increased from 6M to 9M.

As already answered. The same applies to Linux and FreeBSD 64-bit programs. It's normal.

Regards,
Graeme

leledumbo wrote

> Why? At least pointer size takes double space, multiply it with every instances1.5x bigger is not impossible.

Particularly if the binary contains debugging information.

In our previous episode, leledumbo via fpc-pascal said:

> Why? At least pointer size takes double space, multiply it with every instances 1.5x bigger is not impossible.

For memory size, however the question was about binary size. And in instructions usually the full 64-bits of immediate pointers are not stored (and even less so on Windows where addresses are afaik rip relative)

Still the average instruction length goes up. That said, many binary size details are not known.

Dennis wrote

I am upgrading my program from win 32 to win 64 using the new Lazarus 1.8. I discovered my program exe size increased from 6M to 9M.

Just for fun, I wrote a small program to parse Linker Map files and show the image occupation by source object file (~unit).

First lesson: FPC's internal linker is *a lot* better than the GNU linker when it comes to discarding unused parts. Good job there! <http://puu.sh/yR3WX/780bcea8f1.png>
Second lesson: the RTL's system and classes are large, compared to Delphi (at least older versions). They can do more as well, so I'll call that a draw.

And now the on-topic part: this compares an "empty" project (Lazarus: Project->New->Program), compiled for win32 and win64 <http://puu.sh/yR0Qs/6e26a74cc9.png>
As you can see, the win64 image is about a third larger - but not so much because of the code segments (they end shortly after the cyan "bar" for typinfo, before the second occurrence of classes), but more so because of the data sections following. A lot of that is unwind info (.xdata), I'm afraid I don't know what .pdata usually is.

Oh, and I finally know why even simple LCL applications are so large: graphics drags in fcl-image, which includes full support for JPEG, TIFF, PNG and requires pasjpeg, paszlib and others. The widgetset indirection is surprisingly small.

Just though I'd share that.

Am 31.12.2017 00:19 schrieb "Martok" :

Dennis wrote

I am upgrading my program from win 32 to win 64 using the new Lazarus 1.8. I discovered my program exe size increased from 6M to 9M.

Just for fun, I wrote a small program to parse Linker Map files and show the image occupation by source object file (~unit).

Could/would you provide that tool as open source? Does it only work with PE/COFF or also ELF?

First lesson: FPC's internal linker is *a lot* better than the GNU linker when
it comes to discarding unused parts. Good job there! <http://puu.sh/yR3WX/780bcea8f1.png>

Good to know :D

Second lesson: the RTL's system and classes are large, compared to Delphi (at
least older versions). They can do more as well, so I'll call that a draw.

And now the on-topic part: this compares an "empty" project (Lazarus: Project->New->Program), compiled for win32 and win64 <http://puu.sh/yR0Qs/6e26a74cc9.png>
As you can see, the win64 image is about a third larger - but not so much because of the code segments (they end shortly after the cyan "bar" for typinfo,
before the second occurrence of classes), but more so because of the data sections following. A lot of that is unwind info (.xdata), I'm afraid I don't
know what .pdata usually is.

.xdata and .pdata are both used for SEH related data on the non-i386 Windows platforms (x84_64 and ARM as well as the obsolete MIPS and PowerPC targets).

Regards,
Sven

Martok wrote

Oh, and I finally know why even simple LCL applications are so large: graphicsdrags in fcl-image, which includes full support for JPEG, TIFF, PNG and requirespasjpeg, paszlib and others. The widgetset indirection is surprisingly small.

Interesting.

Keep in mind that i386 generates exception handling in code so the "data" of .xdata is basically included in .text on i386.

A lot of that is unwind info (.xdata), I'm afraid I don't know what .pdata usually is.

Sven Barth wrote

Could/would you provide that tool as open source?

Sure! <https://github.com/martok/linkermap>
I have attached the win32 binary as a release.

Does it only work with PE/COFF or also ELF?Since I only very crudely parse the linker map file, I think it should work

regardless of executable format? Wouldn't bet on embedded targets though, they might have a different format. Happy to accept pull requests ;)

Borland Map files are something entirely different (and inconsistent between versions and frontends!), so no easy comparison for now.

.xdata and .pdata are both used for SEH related data on the non-i386 Windows platforms (x84_64 and ARM as well as the obsolete MIPS and PowerPC targets). 

Ah, so they're both exception handling. Interesting to see that is almost as large as the actual code, at least for the "useless" test case.