Am Die, 2002-12-31 um 01.08 schrieb Sander Vesik:
> One important thing that it help soptimise is TLB.
And on which platform? Different architectures have different
implementations of a TLB which would require another optimisation
strategy. Trying to squeeze out a 10% startup improvement on a fraction
of the most commonly used platform where cpu's receive speedups of like
10% per month and applications taking milliseconds to start doesn't seem
to make much sense.
Optimizing for yesterdays architecture would be a different thing but
then again you'll probably not see much negative TLB influences on
a Pentium-II or even worse.
> As for the ordering - its relatively safe bet that you would want to do it
> based on call graph information, whetever static call graph or augumented by
> say call count information.
Well, once could (automatically) gather those information from arc based
profiling of a big application which heavily uses the toolkit and sort
of resembles a common denominator.
> taking care of symbol counts & making sure loading of library dependencies
> that aren't used don't get loaded / resolved for symbols is quite important.
> Its all data the dnamic linker does not have to touch or touches in different
> order (with say lazyloading). I'm not sure how prelinking and direct binding (which
> solaris linker has) differ but probably not much - its definately beneficial,
> and a lot of the benefit comes from not having to search for symbols.
Last time I looked dynamic linking of normal symbols just took a
hashtable lookup which (with a reasonable hashtable) will happen in
constant time.
The argument of having often used functions in the same location to get
them paged in at once and thus perceive lower startup times seems more
likely to me than high benefits of shorter lookup times.
--
Servus,
Daniel
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil