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

OLS: On how user space sucks

Posted Jul 21, 2006 5:27 UTC (Fri) by flewellyn (subscriber, #5047)
In reply to: OLS: On how user space sucks by cventers
Parent article: OLS: On how user space sucks

With respect, I'm not at all sure that layers of abstraction are really necessary to create such a situation. In fact, in my experience, well-abstracted systems where each conceptual layer is well-defined and efficient in and of itself, tend to have less of these sorts of problems going on. I've found that inefficiencies and bogosities of the sort described tend to crop up more in poorly abstracted systems, or where the abstractions are "leaky", exposing too many internals to the next level up. I know this because I have built some.

As a custom web application developer, I have created a number of large, complex systems that do very complicated things; in the process, I have had to reimplement and refactor many of the earlier generations of these systems, because as an application developer in general, I am prone to the very human desire to just get it working. While I try to make sure the applications are properly abstracted, oftentimes the combination of deadlines and the exploratory nature of the process means that I don't do this as well as I should.

This results in system components, libraries, and abstraction layers which at times can be brilliant coups of engineering, and at other (far too frequent) times turn out to be astounding feats of perverse stupidity. In rereading old code, I think for every time I have said "I did that? Damn, that's cool!", I have also said "What the HELL was I thinking?"

Of course, sometimes the design goals are poorly specified, or very broad, or else there are no efficient methods of doing something at the moment, and you just have to wing it with an inferior, but at least functional, solution. That may account for some of the cases above. And then there is the issue of programs whose very purpose is misguided. That may account for one of the other cases given above.

(Log in to post comments)

OLS: On how user space sucks

Posted Jul 21, 2006 9:21 UTC (Fri) by nix (subscriber, #2304) [Link]

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.

OLS: On how user space sucks

Posted Jul 21, 2006 13:10 UTC (Fri) by oak (subscriber, #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).