Re: Size of linked program increasing with new version of GNAT.

["Randy Brukardt" <randy@rrsoftware.com>]

"Tony" <tony7@tele2.se> wrote in message 
news:4a5a3301-958b-41fd-9d1a-7ab35021daa0@googlegroups.com...
> On Friday, December 26, 2014 4:56:16 PM UTC+1, Simon Clubley wrote:
>> It would be interesting for the OP to run the binutils size command on
>> both executables and post the results.
>
> OK, GNAT 3.15p:
> C:\Tony\Ada_program\Tests>size hello.exe -A
> hello.exe  :
> section    size      addr
> .text    62428   4198400
> .data     2244   4263936
> .bss     21124   4268032
> .idata    2416   4292608
> Total    88212
>
> GNAT 2014:
> C:\Tony\Ada_program\Tests>size hello.exe -A
> hello.exe  :
> section      size      addr
> .text      133348   4198400
> .data        1092   4333568
> .rdata      15500   4337664
> .eh_fram    41432   4354048
> .bss        13892   4399104
> .idata       5112   4415488
> .CRT           52   4423680
> .tls           32   4427776
> Total      210460

As should be obvious, the tasking runtime for Ada 2005 and Ada 2012 is 
substantially more complex than that for Ada 95 alone. Since GNAT doesn't 
eliminate the tasking runtime (like Janus/Ada does), the program size is 
going to go up for every new Ada version (and probably every new compiler 
version, too). Even with Janus/Ada, the runtime tends to go up a bit with 
every version (more detailed messages for handling, additional capabilities 
for the heap, etc.)

But that's all irrelevant unless you are targetting a very small embedded 
system. In which case, you'd be better off with a compiler that was designed 
to target very small systems (hint, hint :-). Otherwise, there is so much 
memory available, and so much of the newer capabilities that are probably 
used in a real system, that there really isn't any point in worrying about 
it.

Now, if you have a reference set of programs that double in size, that might 
be relevant. (Lots of memory doesn't mean that it is completely free.) 
Otherwise, it matters about as much as the runtime performance on the old 
Byte Primes benchmark.

                                     Randy.