[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr/lib vs /usr/libexec

ma, 2005-05-09 kello 14:39 -0700, Thomas Bushnell BSG kirjoitti:
> Daniel Jacobowitz <dan@debian.org> writes:
> > You asked why the GNU linker, which does not need to be 'ls' and does
> > not need to look at the list of files in any directory, scaled well
> > with the size of the directory.  That's the question I answered.
> How does ld determine that -latoheun will fail, other than by listing
> the directory O(n)?  How does ld find -lfoo, without searching through,
> on average, half the entries?

I may be completely wrong here, but as far as I understand, ld turns
-lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It
might look into some other directories as well, and it might fill in foo
into some other patterns than "lib%s.a", but basically that is it. It
does not scan the /usr/lib directory, it merely looks up a filename it
knows already.

With modern filesystems, the kernel also does not need to read through
the entires /usr/lib directory listing: modern filesystems user B-trees
or other ways to speed up filename lookups. O(log n), that is, or even
approximately O(1) if a good hash is used.

I suspect this is what Daniel tried to say: that filename lookups aren't
O(n) anymore. This means that the performance reason for
keeping /usr/lib small is gone.

This, of course, has no bearing on whether /usr/libexec should exist or
not for other reasons.

Reply to: