Re: how to get "the big picture" with nm, objdump, size for object size?

[Ilya Murav'jov <muravev at yandex dot ru>]

Nick Clifton ÐÐÑÐÑ:
> Hi Ilya,
>
>> 2. As you can see, debug sections occupy very much space (for
>> executables they hold even more, ~86%). It is too slow to transfer it
>> from object files to libraries, then to executables. What about to keep
>> debug data in a database?
>
> Have a read of the documentation for the objcopy program, especially its
> --strip-debug and --only-keep-debug options.  These options do most of
> what you want, except for speeding up link times by removing the debug
> info before the link.  Removing the debug info at the object file stage
> is a bad idea since the information is incomplete and still needs
> processing in order to make sure that it corresponds to the final
> executable.
>

 Thanks for info, but I need to speed up building.
 Nevertheless I found the solution. At first, here is a little
comparison table for my typical build (one source file is changed):

	| compile, sec	| ar, sec	| ranlib, sec	| link, sec
 -g		2,1		3,15		2,6		2,8
 -g0		1,7		0,33		0,33		2,18

Obviously, ar & ranlib slow down the most because of much debug stuff
(44Mb vs. 10Mb). So, the "solution" is just to avoid intermediate static
libraries (they are evil) and always feed object files directly to
linker (even if one need to build several executables/shared_libs from
the same sources - for developing, "cook" them directly from object files).
 I have the immediate effect as -6 sec to a build. :)

Regards,
 Ilya