Re: Size optimization for objects

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 13-07-10 13:57 , Rego, P. wrote:
>>> and the read size of bla.o is 611 bytes.
>> What do you mean by "read size"? Perhaps this is a typo, and you meant
>> to write "real size"?
>> If you mean the total size of the file bla.o (from the directory
>> listing, e.g "ls -l"), this is not a useful comparison, because the file
>> contains much more data than just the machine code: there are headers,
>> symbol tables, and other debug information -- among other things, the
>> information that "nm" uses to associate machine code addresses with
>> identifier symbols.
> 
> Yes, it is from directory listing. In this case, the 'size' provided
> by "ls -l" should be bigger, right?

Yes, if you consider only the size of the code ("text" segment). For
data, if the program contains uninitialized, statically allocated
variables, the file size can be smaller than the "memory image" size,
because the .o file only describes those variables (name, size, address
or offset) but does not provide values for the variables.

>>> Also, if I run 
>>>    nm --print-size --size-sort bla.exe > bla.txt
   ...
>>> but adding the second column, the result (in Excel I convert it
>>> to decimal before adding) is 8.61147E+12 and the real bla.exe
>>> size is 1512500 bytes, also very different.
>> Again, if by "real size" you mean the entire size of the file bla.exe,
>> the comparison it not useful, just as for bla.o: bla.exe contains a lot
>> more data than just the machine code.
> I don't think 8.61147E+12 is irrelevant.

The fact that this number is so absurdly large is relevant, and the fact
that it is larger than the size of the .o file may be relevant, unless
the number includes the size of uninitialized statically allocated data
-- see above.

Continued in reply to your next message...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .