[plug] Snappy UI

Craig Ringer craig at postnewspapers.com.au
Fri Jun 11 17:01:31 WST 2004


Onno Benschop wrote:

> The interface doesn't feel crisp, it feels like molasses, not something
> you could actually time, but just the feel. OO.o takes six years to load
> and I'm just not a happy camper.

OO.o's load times are very dependent on disk speed. I can tell how much 
memory pressure is on our core server here by launching OO.o, because 
the higher the memory pressure the more of it tends to get flushed out 
of the disk cache. When memory is plentiful or other users are already 
using OO.o, it loads in about 1 second. When it must be loaded from 
disk, it'll take more than 5 seconds to load - on a dual Xeon with 2 
gigs of RAM and RAID 1 / and /usr . Not cool.

I'm seriously considering custom-building OO.o with the-Os compiler flag 
, no -funroll-loops, etc just to see how much faster it goes. It makes a 
big difference with KDE on my laptop (4200rpm disk) - perhaps 30% faster 
to load, and noticably faster to run. Konstruct makes this easy (but 
very far from fast, even with precompiled headers in gcc 3.4).

> Some discussion on /. was crapping on about Linux becoming bloated, and
> I'm beginning to wonder myself. A system boot takes the better part of
> five minutes and all in all it's just not as fast as a bare '95 box
> would be...

Shutdown particularly offends me, actually. It's all well and good for 
databases etc to need to shut down cleanly, but most apps should 
probably be able to be told "save your files and stop accessing the 
disk, the system will be halting in a moment."

I do agree that startup times are getting pretty silly. Testing I've 
done suggests that a large proportion of the startup delay is related to 
simply loading binaries and libraries from disk. If I drop to init 1, 
explicitly read in lots of the files I know will be needed for boot, and 
go back to init 5, boot is incredibly fast. After all, disks aren't 
getting faster as fast as CPUs, or sadly as fast as binaries are 
growing. Therein, I think, lying the problem.

I'm beginning to wonder if internally compressed binaries might even be 
faster, given that most of the time my CPU is mostly idle during boot as 
it waits for disk access.

[snip]

> So, any constructive ideas that won't require me to recompile or
> reformat my disk would be well received.

The only thing I can think of is that graphics chipsets make a 
surprising difference. I work on a wide variety of machines, and I can 
really _tell_ the ones with fast video chipsets, even if they're 
otherwise slow. The difference that dropping a GeForce4 MX or Radeon 
9200 into an older system can make is shocking.

It won't help app startup times etc, but it can make a surprising 
difference to general UI interactivity, especially moving windows, 
redrawing, and scrolling.

Of course, if the XServer folks ever get around to IMPLEMENTING 
ACCELERATED XRENDER SUPPORT - or even optimising XRENDER - that'll help 
a lot, too. As it is, I find my home desktop (with NVidia drivers and 
XRENDER accel enabled) astonishingly snappy.

XFree86 driver quality can also make a susprising difference, but it's 
hard to separate hardware performance from driver performence. A good 
example, though, is the XFree86 driver for the CyberBlade XP. It makes 
S3 feel fast. Under Win2k, the hardware performs fairly decently, so I 
have to assume it's just a bad driver. The same could easily be true of 
i8xx, given Intel's less than wonderful record on releasing hardware specs.

Another thing that helps is, oddly enough, the latest KDE. I find it 
very zippy in comparison to older versions. Of course, that fails the 
"not compiling things" test. Trolltech have done some serious magic with 
Qt 3.3, and it shows.

Overall, though, I have to agree with you. The current state of 
Linux-based operating systems is  in many ways apalling. It's not just 
bloat, though. If you open 4 different apps, you STILL get 4 different 
file open/save dialogs. *ARRGGH*. We also have the kernel vfs, and no 
less than TWO DIFFERENT VIRTUAL FILE SYSTEMS LAYERED ON TOP by GNOME and 
KDE respectively. Driver issues are at least understandable - hardware 
manufacturers are doing their best to make life in that area as hard as 
possible.

Regarding Cameron's points about Gnome-Terminal, you're likely to find 
that is partly because RENDER is so slow.

Finally, I think you'll find that the GNOME and KDE folks are now 
starting to pay attention to the bloat issue. Both frameworks are in a 
fairly stable phase (KDE more so than GNOME, it seems) with more 
attention being paid to polish and speed rather than just getting it 
working properly. The KDE 3.3 release certainly suggests that this shift 
is having a real effect.

Craig Ringer




More information about the plug mailing list