On Wed, Jan 19, 2005 at 09:43:18AM +0100, Bernd Eckenfels wrote: > I agree with you, but dont forget that this micro benchmark does not > really measure the overall effect on the system (i.e. to other > programs, to the number of meta data updates, cach useage) and it > does not take into account slow or unreachable path components (nfs).
Agreed. The intention of the benchmark is not to claim that the operation that ld.so is performing is fast; it's just to provide some quantifiable argument for or against the "system calls are way too expensinve" meme. *My* position is that whilst they are expensive (certainly much more expensive than a function call), they are not _that_ expensive. Before asking here I went thru several mailing list archives. What I found was a general argument along the lines of "don't add _that_ hwcap because that will increase the size of the list of paths that you have to stat(2) in order to find the library and that's slow". In particular upstream doesn't seem to like the idea much. I just can't find the reason why they think the stat(2) call is _so_ expensive that it will hurt system performance. There was some mention of a glib issue with plugins. I couldn't find further data points on that... > So it might be actually noticeable on normal systems (I doubt it). > Just dont stop anyone volunteering from fixing it. I for one are > happy if the strace of a process keeps readable in finite time, so do > system administrators with auditing turned on. I can understand that. I'm just not sure what's to fix in the first place. Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
