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

OLS: On how user space sucks

Posted Jul 20, 2006 22:37 UTC (Thu) by cventers (subscriber, #31465)
Parent article: OLS: On how user space sucks

I'm glad we have free systems -- not only is it possible to spot these
problems, it's possible for people not originally involved in the
programs to step in and fix them.

I guess I'm not at all surprised that some applications behave so
poorly... this is what tends to happen when you stack layers and layers
of abstraction on eachother.

One of the reasons I find programming _so_ entertaining is because I am
challenged by the task of creating the most stable and incredibly
efficient solution I can think of. I guess the same is not true of
everyone :)

What this does tell me is that there is tons of low hanging fruit if we
want to improve power efficiency and performance. So, great hackers,
let's get to work!

(Log in to post comments)

OLS: On how user space sucks

Posted Jul 21, 2006 1:17 UTC (Fri) by sepreece (subscriber, #19270) [Link]

I don't know about Windows, but you could do similar analysis on Unix systems, since 1990-ish, despite their being closed source. Dave's report (which was, indeed, hilarious, and a great lesson for us all) was based on observing the apps from outside (watching their file operations in particular).

OLS: On how user space sucks

Posted Jul 21, 2006 3:40 UTC (Fri) by cventers (subscriber, #31465) [Link]

Right. The difference with free software, though, is that you don't have
to wait for the vendor to fix it (or hope that they care enough). If
something is really itching, you're 100% empowered to scratch it.

OLS: On how user space sucks

Posted Jul 21, 2006 5:27 UTC (Fri) by flewellyn (subscriber, #5047) [Link]

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.

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 (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).