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] |
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] |