This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: ldconfig speedup


Jakub Jelinek <jakub@redhat.com> writes:

> On Tue, Jul 03, 2007 at 01:45:13PM -0700, Ulrich Drepper wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Andreas Jaeger wrote:
>> > What do you think now?
>> 
>> Lot's of formatting and little style/semantic problems all over the place.
>
> ...
>
> I haven't seen any progress with this, so in order to speed up the process
> I tried to address all issues Uli and Jim raised plus several minor or
> less minor things.
>
> Attached is a new patch, plus interdiff from the last patch Andreas posted.
> I have briefly tested it, but nothing extensive.

Thanks a lot Jakub - I just did not had time so far but wanted to follow
up!

> The remaining issues I'd like to discuss before changing them are:

If everybody is fine with your version, I suggest that it goes into cvs
- and the next steps are done on top of it.

> 1) ldconfig uses the /var/cache/ldconfig/aux-cache cache only to speed up
>    mapping of the cache_entry_id -> { flags, osversion, soname }
>    so what's the point of aux_cache_file_entry containing value (aka path)
>    or hwcap?

I don't see a need for them either anymore.

> 2) the aux_entries linked list will usually contain roughly 2000+ entries,

Mine has 2053 - so I agree ;-)

>    isn't that above the count where using a simple hash table or rb tree
>    (hsearch_r is probably a bad idea, as it needs strings as keys,
>    but we could either implement our own trivial hash table
>    (say hashing with nextprime (aux_cache->nlibs) hash table
>    entries with chains), or could grab from libiberty Vlad's hashtab.c
>    (that's probably overkill, we know how many entries we have, no need
>    to ever resize it), or use tsearch).

Yes, some other data structure might be better.

> 3) couldn't the aux-cache entries also contain negative lookups?
>    E.g. we have *.so linker scripts in the directories, that can be
>    cached as cache_entry_id -> { -1, -1, 0 } or something similar
>    to denote non-DSO.

We have so few linker scripts that I doubt this optimization is worth
it.  Otherwise: Yes, it could be done.

Andreas
-- 
 Andreas Jaeger, Director Platform/openSUSE, aj@suse.de
  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
   Maxfeldstr. 5, 90409 Nürnberg, Germany
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]