KDE4 slow

[Aaron J. Seigo]

On Thursday 25 June 2009, Baas, Kevin wrote:
> as a programmer, one has lots of tools at their disposal that an everyday
> user, or even a tester (which essentially isn't much differen)  does not. 
> For instance, in this particular case, a programmer can put timestamps in
> the code, log them to a file, and look for big delays to find any
> bottlenecks.

if it were that simple. in the case of the "plasma is slow"-"it was actually 
kio_http" case, no amount of timestamps in plasma would have identified the 
reported problem.

when it comes to painting issues, we have not only plasma, kdelibs and then qt 
underneath that, but we have dbus for communication (separate process), kded4 
and other daemons (other processes) and even x.org doing the actual painting 
(separate process, again)

profiling is certainly a useful tool (and in qt 4.6 qgrahpicsview has received 
a huge overhaul due to various profiling that's been done, to very impressive 
effect already), but we face a slightly more complicated set of challenges.

> As to what "part" of KDE (or "not KDE"), i believe the critics have already
> made that clear: the window manager.  (this may be "the desktop" as well,
> but in any case the GUI). 

except that that doesn't really tell us anything about the problem, only 
something that adjusts the symptoms, or at least appears to adjust the 
symptoms.

> Hard for a user to get much more specific than
> that: "it takes a while to open and close or window."  "It takes a while to
> shut down KDE."  I believe someone actually counted the seconds it did each
> observable task for while shutting down.

unfortunately that input is hardly useful without further digging.

> As to "where in the code the problem(s) actually lie" - if someone knew
> that, they would have already fixed it.

right, so i'm suggesting we need to find those locations.

> As to "what the cause of the
> problem(s) are"  that has already been stated:

those are the symptoms/results of the underlying problem, not the causes.

> "the severity and type of the problem(s)", this has already been answered,
> too:  type: performance.   severity: would prefer to use KDE 3 because of
> it.

let me clarify that point then, because you've misunderstood me:

once we know where a problem is, we need to know what kind of problem it is 
(wrong algorithm? driver / hardware quality issues? poor build? due to 
blocking IPC? etc...) so we know what kind of solution to start crafting and 
we also need to know how severe that particular problem is so we know how to 
prioritize that effort so we achieve maximum results.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-quality/attachments/20090625/1bf2d766/attachment.sig