This is the mail archive of the
mailing list for the glibc project.
Re: [open-source] Re: Wish for 2002 ...
Russ Allbery <email@example.com> writes:
> You should not add those functions because it will make glibc a tiny bit
> slower for every other program that doesn't use them and the speed benefit
> for the programs that do use them is almost nonexistent and not worth the
> additional glibc maintenance load and potential speed hit for every other
> program that uses the library.
There are two possible ways it makes things slower for "every other
1) If the functions are loaded into memory, there is that much more
competition for virtual memory resources.
2) With the functions in the library, access to the important
functions becomes more non-local, and fragmented, with TLB and
other paging problems.
3) If the functions are part of glibc, the time to mmap the library
Number (1) is not true: if even two programs are using the function in
their local text segment, then that's worse than having the function
in glibc from a total memory point of view.
Number (2) might well be a problem, but it has solutions: reorder the
functions in the library carefully.
Number (3) is a kernel problem; there is no reason mapping a large
segment should be any more expensive.
So maybe there's something I've missed, but everyone is telling me
"everyone knows XXX" without explaining the reason why I should
> One of the significant problems with free software and open source
> development in my opinion, and possibly with closed source development as
> well although I have less experience there and can't be sure, is that the
> cost of new features is underestimated because only the initial
> development costs are considered. Every single time you add a line of
> code to glibc, and particularly an external function, you're incurring a
> long-term cost.
I agree completely. But if you don't add these particular functions
to glibc, you simply push that cost off onto other people--more of
them--who are more poorly equipped to do them well.