Re: Baby X is bor nagain

On Mon, 24 Jun 2024 18:10:20 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

bart <bc@freeuk.com> writes:

On 24/06/2024 18:02, Scott Lurndal wrote: 

bart <bc@freeuk.com> writes: 

On 24/06/2024 16:10, Michael S wrote: 

 

But my project has much more than 34 modules. 164 modules
compiled during build + several dozens in libraries. 

>
Does that matter? My example is a smaller project, but I'm
comparing the rate of compilation not total time.
>
If you want a bigger example, yesterday I posted one involving
140 .c files, total EXE size is 5MB (don't know .text as this is
ELF format). 

 
Why do you believe that the size of the executable is interesting?
 

>
Well, what metric IS interesting?
>
You seem to not care whether an executable is 10KB, 10MB, or 10GB.
You really don't think there's correspondence with build-time? 

 
No.  The ELF file contains a lot of stuff that never gets
loaded into memory (symbol tables, DWARF section data, etc);
writing to the object files by the compiler is an insignificant
component of the overall compile time.
 
Build time is not related in any way to the size of the
ELF.
>

That's why in my original post in this sub-thread, in order to give
a feeling of the size of compiler's job I gave the size of text
segment rather than size of the elf.
The size of text segment is, of course, not a good measure of
compiler's job, esp. when we are trying to compare compile jobs for
different target architectures, but it is less bad than any alternative
measure [that is not too hard to gather] that I can think of.
If you can think about anything better, please tell us.

Disk space is cheap and plentiful.
 
 

>
The .text was also something introduced by MS. 

 
I don't understand this comment.   .text predates any MS
compiler by more than a decade.