Re: Some initial thoughts about 2.4

[Owen Taylor <otaylor redhat com>]

Daniel Egger <degger fhm edu> writes:

> Am Mon, 2002-12-30 um 17.01 schrieb Owen Taylor:
> 
> >  - Implement object file reordering for Linux
> 
> What I did some time ago was writing a script (for The GIMP) which
> combined all source files into one by concatenating all source files
> together, and including all header files (once) into the whole mess.
> After that step some cleanup happened and the whole thing was compiled
> as one piece. It led to a smallish improvement in code size and speed
> (~3% smaller object code) and reduced overall compile time.
> 
> This probably could be done for Gtk+ as well... That having said doing
> object file reordering would probably lead to a much smaller improvement
> if any at all; this is more a matter for C++ object files where vtable
> lookups can be pretty expensive.

The idea of object file reordering is to put infrequently used functions
into different pages than frequently used functions. GTK+-2.0 has
a lot of code:

$ size .libs/libgtk-x11-2.0.so.0.200.0
   text    data     bss     dec     hex filename
2104613   33092    9032 2146737  20c1b1 .libs/libgtk-x11-2.0.so.0.200.0

Much of this code isn't used that often or at all in a typical app,
and it isn't well separated out from the rest. (Look at gtkwidget.c,
say) By reordering the functions in the executable, I think it would
be possible to reduce the amount of pages that have to be loaded off
the disk for the first app that uses GTK+ by a significant
fraction. Of course, the more GTK+ apps you have open, the less it
matters.

Relocations and prelinking are something where C++ benefits more than
C (though prelinking did make a 10-20% difference for gnome-terminal
in some timings i did), object file reordering should benefit C and
C++ more or less equally.

Regards,
                                        Owen