OLS: On how user space sucks
OLS: On how user space sucks
Posted Jul 20, 2006 22:37 UTC (Thu) by cventers (guest, #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!
Posted Jul 20, 2006 23:03 UTC (Thu)
by tomsi (subscriber, #2306)
[Link] (2 responses)
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.
Posted Jul 21, 2006 1:17 UTC (Fri)
by sepreece (guest, #19270)
[Link] (1 responses)
Posted Jul 21, 2006 3:40 UTC (Fri)
by cventers (guest, #31465)
[Link]
:)
Posted Jul 21, 2006 5:27 UTC (Fri)
by flewellyn (subscriber, #5047)
[Link] (3 responses)
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.
Posted Jul 21, 2006 9:21 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
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.
Posted Jul 21, 2006 13:10 UTC (Fri)
by oak (guest, #2786)
[Link]
Actually when I half a year ago installed Breezy on a P166, I found
When I straced the Xlib programs, most of the time seemed to be going to
Posted Jul 21, 2006 17:40 UTC (Fri)
by Tet (guest, #5433)
[Link]
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).
OLS: On how user space sucks
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
Right. The difference with free software, though, is that you don't have OLS: On how user space sucks
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
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*.OLS: On how user space sucks
> If you're not told how expensive some function call is, the only way to OLS: On how user space sucks
> 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),
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. :-)
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.
What this is really telling us is that we need better docs, I think.
OLS: On how user space sucks