OLS: On how user space sucks [LWN.net]

OLS: On how user space sucks

Posted Jul 21, 2006 9:21 UTC (Fri) by nix (subscriber, #2304)
In reply to: OLS: On how user space sucks by flewellyn
Parent article: OLS: On how user space sucks

That one thing the C++ standard library got right, which I wish other interface designers would follow: treat the time and space complexities as *part of the interface*, document them, and *do not increase them*.

If you're not told how expensive some function call is, the only way to tell is to profile the hell out of it *on a system where n happens to be large* (so fontconfig sloth might not be obvious unless, like davej, you have many thousands of fonts), or to look deeply into the internal implementations of every function you ever use (no chance).

What this is really telling us is that we need better docs, I think.

(Log in to post comments)

OLS: On how user space sucks

Posted Jul 21, 2006 13:10 UTC (Fri) by oak (guest, #2786) [Link]

> If you're not told how expensive some function call is, the only way to
> tell is to profile the hell out of it *on a system where n happens to be
> large* (so fontconfig sloth might not be obvious unless, like davej, you
> have many thousands of fonts),

Actually when I half a year ago installed Breezy on a P166, I found
that simple Xlib based programs (xeys, xclock...) took actually twice
as long (10 secs) to start than e.g. Gnome calculator or Abiword
which were using fontconfig through Xft through Pango. So, I would
say that it's an improvement over what was before. :-)

When I straced the Xlib programs, most of the time seemed to be going to
loading information about Asian bitmap based X fonts. It would have been
nice if the other bitmap fonts (for example everything besides the cursor
and fixed font) would have been in separate package that is installed only
when needed.

OLS: On how user space sucks

Posted Jul 21, 2006 17:40 UTC (Fri) by Tet (subscriber, #5433) [Link]

What this is really telling us is that we need better docs, I think.

Well, yes. But also better tools. SystemTap is a perfect example of a "better tool" in this case. It lets you look at problems at a system-wide level, rather than on a per-process basis, and you'd be amazed at some of the things that show up, in places you're least expecting. It turns out that on my desktop, ioctl() and poll() are called more than any other system call, by an order of magnitude -- where intuitively (and based on experience on previous systems), I'd have expected gettimeofday(). SystemTap provides an easy way to track down the culprit, too (in this case, the java_vm, even when no applet is running -- but being closed source, there's sadly nothing that can be done to fix it).