Re: /usr/lib vs /usr/libexec
Lars Wirzenius <email@example.com> writes:
> 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.
Right, and "open" is O(n) on just about every system. If that's not
true on ext2, then that's good news, and I'm surprised.
> 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.
Actually, even systems as old as ITS used better than O(n)
directories. It's Unix that has historically stunk. It's not a
modern/old thing, it's a Just Do It thing.
Which Linux filesystems have better than O(n) performance on open?