Re: Speed suggestions (previously about laptop performace)

[hobbit aloss ukuu org uk]

On Fri, Aug 02, 2002 at 05:45:27PM +1000 or thereabouts, David T. Bath wrote:
> On 02-Aug-2002 Telsa wrote
> > GNOME speed (or lack of it) concerns me. Although this is slightly
> > separate from the broader issue of "GUI performance on laptops
> > running Linux".
> 
> Apparently, the KDE3 speed improvement was due in no small part to
> a mem-leak-killfest using a kde memory profiler/debugger that had
> just been developed.

That has to be Valgrind, which just hit version 1.0. It lives at
http://developer.kde.org/~sewardj/ I should note that, as Julian
pointed out, the URL doesn't mean it won't work on Gnome apps :) 

I am not a hacker, but I am told it is very very good indeed.

> Maybe a similar festival could happen for Gnome stuff using memprof?
> I'd imagine the KDE teams will be happy to tell you how they
> organized their fest.

Doesn't have to be memprof: Valgrind will handle most Gnome apps.
Back in February it had some trouble with threaded apps. I don't
know whether that's still true. 

> To me, both KDE and Gnome seem to have many filehandles open, usually
> to config or temporary files.  This can push system limits when there
> are a number of users on the box, and you have to kill the more long-lived
> sessions and/or fiddle under /proc/sys.  GConfig might help solve this
> problem.

Some Gnome hackers have been using profiling tools and achieving
big improvements. I think that's what Michael Meeks has been doing
with bonobo? (Certainly Nautilus on Gnome 2.0 is frequently 
reported to be faster than Nautilus on Gnome 1.4.) You don't
even need the funky tools: Nautilus' "now we load the fonts for 
the seventeenth time" propensity was spotted using strace and
aiming Nauti at a _very_ large directory over NFS. Fixing it
made a noticeable difference. 

I have Gnome 2.0 (from the RH beta) running on a Cyrix MediaGX/233
with 96Mb of RAM. It's not remotely fast but it is just about 
usable for my purposes (which generally involve lots of gnome-terminals 
on plain backgrounds and destroying everything I can).

I have been told that a really slow box shows bottlenecks very
well. So if someone tells me the commands to run, I will cheerfully
send them the results! 

I would very much like to see results like those Michael achieved 
happening everywhere. 

> However, I believe the problem both for Gnome and KDE is that users
> have little idea which tools are quality products (Gimp, Konqueror)
> and which use Gnome/KDE APIs, but are poorly written with consequential
> performance drops.
> 
> This could be addressed by a vetting process, with a "star" scoring
> system administered by respected people, checking for basic good
> behaviour in programs.  Just because it *looks* like a flashy Gno
> or KDE app does *not* mean it is well written.

This is an interesting idea. It would also be good if someone
could update the gnome-docu/white-papers/ProgrammingGuidelines/
files to include things like this. I don't know where people
go to find information about "Here are ways to profile; here
are examples; here are tools you can use" and so on. 

gnome-docu/white-papers/ChangeLog was last touched almost exactly
two years ago. I suspect it's in desperate need of updating.
(Hint, hint, especially those on the Cc: line!)
 
> Years ago, the source of all good things was comp.sources.unix,
> and we could not get our code in there unless it conformed to
> certain standards, and the administrator (Paul Vixie at DEC)
> had eyeballs the code for malice/stupidity.  This provided
> discipline when we contributed, confidence when downloading,
> and justification to managers, who had even less idea of the
> advantages of open source than they do now.  (How do you get
> below -274 degrees Kelvin?)
> 
> Thus, while technical improvements are necessary, organizational
> expertise (and most of us are *hopeless* in that domain) is
> also required.
> 
> Sorry about being less active over the last year or so, I've been
> unwell.

Sorry to hear that. Very nice to see you back though.

Telsa