Re: Speed suggestions (previously about laptop performace)

[Michael Meeks <michael ximian com>]

Hi Telsa,

On Sat, 2002-08-03 at 14:34, hobbit aloss ukuu org uk wrote:
> > 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.

	Sadly, that's pretty much something that shouldn't help improve Gnome
performance. I don't think our performance problems are due to memory
leaks making allocation more expensive. All our performance problems are
algorithmic, and Valgrind just can't help with that.

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

	It is rather good.

> 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. 

	Memprof produces far more useful memory profiling, so we can find who
is using how much memory and for what.

	I also have patches, pending Kris' return to do itimer profiling using
the same engine, a fusion of 'eazel-tools/prof' and 'memprof', which is
rather nice [ although symbol problems, ie. it often lies about the
methods taking the time, make it less effective ].

> 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.)

	Alex and I did a lot of work on Nautilus; while I did some work to
speedup Bonobo - the _vast_ majority of performance improvement in
Nautilus was simple sloppiness in nautilus & gnome-vfs.

> 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. 

	strace -ttt -f <app> is great, although I've seen some amazing 'time
goes backwards in the same process', 'same open reported 3 times' type
issues in my strace logs [ which seems just incredible to me ].

> 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).

	The terminal in the RH beta [ if it is VTE ] has very acute performance
problems that make the desktop feel dog slow. Certainly running nautilus
on my 128M, 366 laptop, was almost as snappy as on my 256M, 650 laptop -
which in itself is rather odd.

> 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! 

	If you do: cvs -z3 checkout -r speed_prof memprof, build, install [
this is rather a broken build ], and run it on whatever you think is
slow - then it's possible that hitting profile after it's done will give
you some idea of where the problem is. Unfortunately the result set
needs interaction to be really useful, and [as I say] the symbol mapping
seems pretty bogus to me.

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

	You're too kind - lots of other people helped fix nautilus performance,
particularly Alex L.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers