Am Mon, 2002-12-30 um 20.02 schrieb Owen Taylor:
> 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:
Interesting, this is a new idea to me. However given that a page is
traditionally 4 or 8k I'm wondering how much functions one can group
together considering that the whole library has 2.1M (from your
statistics). Which effects would we want to trigger? Better utilisation
of I-Cache? Prevent paging? If paging, which sort of paging?
> 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.
Okay, say the library is mmapped in and the OS is configured to not
do readahead but instead page in the missing functions in fractions of
whole pages as we walk through the application, how much gain would you
estimate by improving locality? And how would we figure out which
functions to put together considering that different applications surely
have a completely different footprint?
> (though prelinking did make a 10-20% difference for gnome-terminal
> in some timings i did)
This is interesting. Dynamiclinking in the C case is bog simple and
really hard to speed up. How did you achieve that?
Do you have any pointers or papers? This looks like an interesting
area for some research.
--
Servus,
Daniel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil