Presentation on theme: "Making GNOME Fast Federico Mena-Quintero"— Presentation transcript:
Making GNOME Fast Federico Mena-Quintero firstname.lastname@example.org
Where we stand now ●... in the air? ● Eugenia: “GNOME feels heavy” ● Users: “Windows XP is faster on my P500 128 MB” ● WE HAVE NO IDEA
The problem with not measuring ● http://osnews.com/permalink.php?news_id=12037&comment_id=38087 c has nothing to do with gtk+ being slow. Gtk is slow for several other reasons: 1.) It renders widgets as SVG's on the fly (2.8) 2.) It dynamically allocates widgets physical space (I believe QT does this too) 3.) Pango is slow (this is what I've read) 4.) It's very very very structured. You'll find that if you read through the GTK API docs, it's a parent-child class structure of widgets which all bases off glibc's types. It's a PERFECT example of how c++ is a superset of c ;) (technically it's not, but logically it is). “ ”
Non-Goals? ● “Make Foo faster” ● How much faster? ● This doesn't let us see regressions
● Make GtkFileChooser appear in <0.1 sec ● Make Nautilus open a folder in <0.1 sec ●... you see the pattern ● Make Foo happen in < $time sec ● This lets us blame people notice if things become slower Set concrete goals
● GtkFileChooser, Nautilus (“aren't they the same thing?”) – My benchmark: The Midnight Commander ● Open the Applications menu in <0.1 sec ● Make Gedit start up in <0.5 sec ● Make GNOME login in < 1 sec – Stand up and applaud for Lorenzo, Rodrigo, Nat, Jdub Some nice goals
Perceptual stuff ● Flicker -> annoying/SLOW ● Not keeping up with mouse -> SLOW ● Not keeping up with typing -> OH MY GOD, I'M GOING BACK TO WINDOWS
Flicker ● Evolution, switch between messages ● File chooser, appears blank and then fills up
Not keeping up with mouse ● Control center / Keyboard / Layouts / Add... -> resize the window
Plain sluggish ● Evolution, switch between mail/calendar/contacts ●... insert your favorite moment here
Measure! ● Use a profiler ● gprof is useless – doesn't work with shared libraries, dlopen(), threads, phase of moon... ● Sysprof rocks! – Everyone applaud Søren ● Strace
A day in profiling land ● You'll have to run the same thing many times ●... and extract results ●... and parse them with your brain ● Automate all that shit – (Also, that automatically gives you a regression test that is easy to run)
Trim the fat in order (but ask the profiler first) 1. Excess work 2. Excess I/O 3. Bad algorithms 4. Bad memory access patterns 5. Micro-optimizations (function call overhead, mis-predicted branches, CPU-level foo) ● Most of GNOME is probably around (1) and (2). ● If you get to (4, 5), you are probably doing very well.
Excess work ● Your code is doing things it doesn't need to do. ● Example: file chooser in OPEN mode was building and populating the completion entry... which never gets shown. ● How did I find it? Sysprof. ● Solution: don't even create the entry in OPEN mode.
Excess I/O ● All over the place. We open/stat/access too many files. ● Example: file chooser was loading $cwd in addition to the folder it displays at startup. ● How did I find it? Strace. ● Solution: load $cwd only if no folder has been explicitly set.
Bad algorithms ● We abuse GList, end up with O(n 2 ) algorithms. ● Example: with large directories, the file chooser spends all its time walking GLists. ● How did I find it? Sysprof. ● Solution (not yet implemented): arrays.
Bad memory access patterns; micro- optimizations ● Uh, I haven't got to that point yet.
Amdahl's Law ● For pedants: ● A picture is worth a thousand hours spent in OpenOffice's equation editor A B Two independent parts Original process Make B 5x faster Make A 2x faster P = part to be optimized S = speedup for that part
Sysprof ● Demo! – GO INSTALL IT NOW! ● Systemwide sampling profiler – Lets you see processes that contribute to something ● Kernel module interrupts all running processes N times per second; takes snapshots of the call stack ● Caveat: won't tell you about time spent doing I/O
Strace ● strace -ttt -f -o logfile.txt./myprogram ● -ttt = give me timestamps ● -f = trace child processes ● Trick: sprinkle this in your code: access(“MARK: we are here”, F_OK);
/usr/bin/time ● Not the bash “time” command ● Gives you user time, kernel time, page faults ● WTF doesn't it give you memory values? Linux sucking as usual?
Dtrace ● Solaris only ● Really Fucking Cool(tm) ● John Rice, are you here?
What I'm doing ● File chooser is dog slow ● Goal: pop up in less than 0.1 sec ● Pango – will benefit the whole desktop – RENDERING IS NOT SLOW! – MEASURING TEXT IS SLOW! ● GtkTreeView – will benefit plenty of programs
GtkWidgetProfiler ● On hold right now ● Goal: easy way to time milestones in widgets – Time for instantiation? – Time for realization? – Time for sizing? – Time for map? – Time for expose? – Time for re-expose? ● Should probably be GtkWidgetTimer
Pango – measuring text ● Look at each character, group chars by script/font/direction/etc. ● Shape the glyphs in each group ● Measure each group ● No clear hotspots ● Compiler optimizations interesting ● Improve data/code locality? ● Micro-optimize?
Looking for something to do during the Summit? ● Install sysprof ● Pick a slow operation ● Hack the program to run $op in a loop ● Run sysprof/strace/etc. ● Find what is slow ● Tell us at the end of the Summit ● Fix it when you get home!