[plug] Snappy UI

[Craig Ringer]

Cameron Patrick wrote:
> Craig Ringer wrote:
> 
> | >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.
> 
> Yeah, and Onno mentioned he had a laptop drive too.  Every laptop I've
> seen has loaded OOo much slower than most desktop machines - even when
> the laptop had the faster CPU.  Conclusion: laptop drives suck.

Indeed. You can get quite fast 2.5" drives now but they don't seem to 
get used much in laptops, presumably because of cost. It's unlikely to 
be heat or power as the new 7200rpm laptop disks are shockingly 
efficient, too.

I'm going to be upgrading my laptop with a 7200rpm disk soon. Sure, the 
laptop is only a PIII/800 with 384MB of RAM (I did say /desktops/ with 
less than a gig in my other mail), but it's quite powerful enough and 
mostly held back by an awful 4200rpm disk. I suspect the PIII/800 is a 
match for a 1.5GHz P4 Celeron anyday.

> I suppose that makes me feel not too bad about how long it takes to
> start on my desktop :-/

Yeah. It's worth noting though that users on this box do have to share 
disk access, and the disks are rarely able to service only one request 
at once, so that increases the startup time from disk considerably. Even 
my laptop doesn't take much longer than that.

> | [recompiling with -Os]
> | It makes a big difference with KDE on my laptop (4200rpm disk) -
> | perhaps 30% faster to load, and noticably faster to run.
> 
> I would imagine that on a Celeron the reduced cache pressure would be
> a big advantage.

My laptop is a PIII/800 so cache isn't too much of an issue. Even so, I 
suspect it helps. Mostly it'll be binary size improvements.

On the other hand, I've started building with -Os even on the dual Xeon 
server. It has 512k of cache per processor (it's a cheap Xeon box) but 
even so, on a multiuser box that means more chance of more things being 
in cache. It'll also reduce pressure on the RAID array. It should be 
interesting.

On an aside, I'm increasingly coming around to the FreeBSD or Gentoo 
view of package management for long-lived hosts. I tend to prefer 
FreeBSD's way though, where the core system is essentially static but 
small, and everything else builds on top. I'm beginning to seriously 
consider running Gentoo in a UML for our _production_ server, so I can 
have the LTSP users on an up-to-date desktop environment without having 
to to change the core server with its mail services etc. If anybody has 
done this or anything similar, I'd be very interested in hearing about it.

> | 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.
> 
> They probably would be.  The swsusp folks found that LZO compressed
> images were faster than straight uncompressed ones; gzipped ones were slower.

I'm still using the in-tree 2.6 swsusp on my laptop. I really must try 
out the swsusp2, because the in-tree one is slow and a bit dodgy.

> A while ago I read something by Keith Packard (?? I think... the
> RENDER guy, anyway) suggesting that the current software RENDER
> implementation is about as lousy as they come and has a lot of room
> for improvement, it's just that no-one has done it yet.

He should know, too - he wrote it. As an example / reference 
implementation. It's obvious it wasn't intended to be deployed as-is, 
but instead optimised by driver authors. *sigh*.

> I want RENDER acceleration on my Radeon - drawing antialiased text
> just shouldn't slow a 2GHz+ machine to a crawl.

It's pretty nice with my GeForce 4 Ti 4800 :-)
Even Mozilla is reasonably fast.

> | 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.
> 
> No it doesn't.  packages.debian.org/kdebase says testing has kde 3.2.2-1.

I should've added "unless you run Debian Sid." Silly me. Even so, it's 
probably built with traditional "make-it-go-faster on the CPU, size be 
dammed" flags. (I'd be interested in confirmation of exactly what flags 
they _do_ use, btw), so if you want to change that you're still up for a 
long compile job.

> KDE 3.3 released?  You been borrowing Shayne's time machine again? :-P
> KDE 3.1 was smaller and faster than 2.2.  KDE 3.2 is faster again.

I was referring to 3.2 with Qt 3.3, sorry. It's _incredible_ over remote 
X, by the way. I can use the latest KDevelop over a 512k/256k line 
between home and work, and it's sort of OK. That makes it about an order 
of magnitude faster than previous versions, with only another order of 
magnitude needed to make remote X apps with Qt stand up beside RDP or 
ICA without total humiliation.

Craig Ringer