Club Silencio

Performance Work

Inspired by the recent performance love day and by the awesome work of Luis Menina and Federico about the slowness of ‘replace all’ in gedit, yesterday evening I decided to give it a look myself.

Federico explained in detail the first big offender (setting the sensitivity of the ‘find again’ menu item on every match), however once fixed that issue, ‘replace all’ is still fairly slow, so we need to continue our quest.
Next thing showing up in the profile is the statusbar code: the cursor position on the statusbar is updated every time the cursor moves, but that means that during ‘replace all’ the statusbar text changes on every match without need!

That said, I didn’t feel like hacking on the old gedit codebase: note that these issues do not affect the new_mdi branch in the same way, since we changed our internal search api. The code there is not yet finalized there is no point in optimizing it yet, however these findings are very useful and will teach us to avoid making the same mistakes.

So I looked what was next in the profile… things started to become a bit less evident: if I was a serious person I should have fixed the statusbar issue and remeasured in order to get a better signal to noise ratio, but… ;)
Anyway, I spotted gtk_text_iter_forward_to_line_end taking up a few percents, which looked a bit strange. The first question was: “what has forward_to_line_end to do with search and replace?”. It turned out that GtkSourceView uses it to deal with line markers: fair enough.
So the next step was coming up with a simple test case: the easiest thing to do was taking a GtkTextBuffer, put a line of text in it and move an iter to the end of the line in a loop 5000000 times (where 5000000 is the number of iterations that made the test case take about one minute). Such a stupid test case worked surprisingly well: profiling it with the awesome sysprof clearly showed the two major offenders: _gtk_text_line_char_byte_to_offset and gtk_text_iter_backward_chars.
Both functions need to deal with obtaining an offset in bytes given an offset in number of characters (each character may be more than one byte in utf8) and both functions used a loop to calculate it: guess what? glib has a function that can do that for us, called g_utf8_offset_to_pointer. Such a simple change, which is just a code cleanup, makes the test case take 40 seconds instead of 67 (according to /usr/bin/time).
I am sure that things could be optimized further or maybe, even better, we could try to speed up g_utf8_offset_to_pointer since it’s used in many other places, but this example shows that you don’t need to be a guru to improve things :)

Apropos of performance… I stumbled in this page on apple developers pages which suggests using fts_* functions (see man fts) to traverse file hierarchies: has any of the nautilus/vfs guys ever looked into them?

770

I forgot to mention that I got a Nokia 770 some time ago: the device is awesome, especially the screen, though I have one dead pixel in the bottom right corner :(
Fortunately is only noticeable when playing marbles fullscreen ;)
I played a bit with the device (xterm, ssh and all the various stuff all other people have already talked about). I also installed scratchbox and whipped up a quick port of glightoff: developing with maemo it’s easy and fun, the only problem I enocuntered was that the svg graphics didn’t work. I need to find some more time to play with it some more.