Re: [ck] Re: [patch][rfc] quell interactive feeding frenzy

[jos poortvliet]

Op woensdag 19 april 2006 10:37, schreef Andreas Mohr:
> Hi,
>
> On Mon, Apr 17, 2006 at 10:08:08AM +1000, Con Kolivas wrote:
> > On Monday 17 April 2006 04:44, Andreas Mohr wrote:
> > > Hi,
> > >
> > > On Sun, Apr 16, 2006 at 09:22:59AM +1000, Con Kolivas wrote:
> > > > The current value, 6ms at 1000HZ, is chosen because it's the largest
> > > > value that can schedule a task in less than normal human perceptible
> > > > range when two competing heavily cpu bound tasks are the same
> > > > priority. At 250HZ it works out to 7.5ms and 10ms at 100HZ.
> > > > Ironically in my experimenting I found the cpu cache improvements
> > > > become much less significant above 7ms so I'm very happy with this
> > > > compromise.
> > >
> > > Heh, this part is *EXACTLY* a fully sufficient explanation of what I
> > > was wondering about myself just these days ;)
> > > (I'm experimenting with different timeslice values on my P3/450 to
> > > verify what performance impact exactly it has)
> > > However with a measly 256kB cache it probably doesn't matter too much,
> > > I think.
> > >
> > > But I think it's still important to mention that your perception might
> > > be twisted by your P4 limitation (no testing with slower and really
> > > slow machines).
> >
> > You underestimate me. Those cpu cache effects were performance effects
> > measured down to a PII 233, but all were i386 architecture. As for
> > "perception" this isn't my testing I'm talking about; these are
> > neuropsychiatric tests that have nothing to do with pcs or what processor
> > you use ;)
>
> OK, but I was not worrying about the interactivity aspects, rather the
> performance aspects (GUI updates of KDE 3.5.2 on P3/450/256MB on Ubuntu are
> about as slow as medium-hot lava). While of course it's mostly KDE (and
> probably also the S3 Savage driver/card) which is to blame here,
> I'm trying to first do as much as possible at kernel level before
> eventually going higher up the chain...

if it's slow redrawing, i'd blame the video driver or X, not KDE/Qt - tough 
you might want to try another style and windowdecoration. plastik is 
generally speaking quite fast, or try the 'light' style. Xorg xcomposite 
might help too, but i guess your video card won't like that :D

slow app startup will be better in Kubuntu Dapper+1, as they will finally 
incorporate the new fontconfig (*g* i hope so) and use GCC's C++ symbol 
invisibillity in KDE/Qt. those both can give speedups in the area of 10-20%, 
so that should be noticable. KDE 3.5.3 also will also have a few other 
patches to speed up the KDE startup process, so - faster login, too.

now with al this, its hard to imagine KDE 4 will again sport some 20/30% 
speedup due to reduced memory usage/binary size ;-)

> Andreas

Attachment: pgp00000.pgp
Description: PGP signature