Re: ideas on improving the performance of gtk_tree_view

[Nicolas Setton <setton adacore com>]

> Nicolas, can you get another profile using Markku's patch?

Most certainly!

A couple of preliminary remarks.

I have observed a startup time increase of between 20% and 30%.

When scrolling, here is what I observed:
  - when displaying the selected row, performance is as bad as  
before (scrollbars take between 5 and 15 seconds to react)
  - when not displaying the selected row, performance is acceptable  
(scrollbars take between 0 and 2 seconds to react, and I'm compiling  
at -O0)

An interesting point to note is that this seems due to the drawing of  
the keyboard input rectangle (the dotted lines rectangle): when I  
select a row with the mouse, the interface is snappy, both for  
selecting and for scrolling (between 0 and 2 seconds response time),  
but when I then change the selected row using Up or Down keys, the  
interface takes around 10 seconds to highlight the newly selected row.
Maybe the experts will have an idea why this is so?

Let's have a look at the relevant time profile (line N calls line N+1):

Self	Total	Library			Symbol

0.0%	73.7%	libgtk-x11-2.0.0.dylib	gtk_main	
0.0%	73.7%	libglib-2.0.0.dylib	g_main_loop_run	
0.0%	73.7%	libglib-2.0.0.dylib	g_main_context_iterate	
0.0%	73.6%	libglib-2.0.0.dylib	g_main_context_dispatch	
0.0%	73.6%	libglib-2.0.0.dylib	g_main_dispatch	
0.0%	71.8%	libglib-2.0.0.dylib	g_idle_dispatch	
0.0%	71.8%	libgdk-x11-2.0.0.dylib	gdk_threads_dispatch	
0.0%	71.8%	libgdk-x11-2.0.0.dylib	gdk_window_update_idle	
0.0%	71.8%	libgdk-x11-2.0.0.dylib	gdk_window_process_all_updates	
0.0%	71.8%	libgdk-x11-2.0.0.dylib	gdk_window_process_updates_internal	
0.0%	71.8%	libgtk-x11-2.0.0.dylib	gtk_main_do_event	
0.0%	71.8%	libgtk-x11-2.0.0.dylib	gtk_widget_send_expose	
0.0%	71.8%	libgtk-x11-2.0.0.dylib	gtk_widget_event_internal	
0.0%	71.8%	libgobject-2.0.0.dylib	g_signal_emit	
0.0%	71.8%	libgobject-2.0.0.dylib	g_signal_emit_valist	
0.0%	71.8%	libgobject-2.0.0.dylib	signal_emit_unlocked_R	
0.0%	71.8%	libgobject-2.0.0.dylib	g_closure_invoke	
0.0%	71.8%	libgobject-2.0.0.dylib	g_type_class_meta_marshal	
0.0%	71.8%	libgtk-x11-2.0.0.dylib	_gtk_marshal_BOOLEAN__BOXED	
0.0%	71.8%	libgtk-x11-2.0.0.dylib	gtk_tree_view_expose	
0.1%	71.5%	libgtk-x11-2.0.0.dylib	gtk_tree_view_bin_expose	
0.0%	67.0%	libgtk-x11-2.0.0.dylib	gtk_paint_focus	
0.0%	67.0%	libgtk-x11-2.0.0.dylib	gtk_default_draw_focus	
0.0%	67.0%	libcairo.2.dylib	cairo_stroke	
0.0%	67.0%	libcairo.2.dylib	cairo_stroke_preserve	
0.0%	67.0%	libcairo.2.dylib	_cairo_gstate_stroke	
0.0%	67.0%	libcairo.2.dylib	_cairo_surface_stroke	
0.0%	67.0%	libcairo.2.dylib	_cairo_surface_fallback_stroke	
0.0%	66.9%	libcairo.2.dylib	_clip_and_composite_trapezoids	
0.0%	66.8%	libcairo.2.dylib	_cairo_traps_extract_region	
0.0%	66.8%	libcairo.2.dylib	_cairo_pixman_region_union_rect	
0.0%	66.8%	libcairo.2.dylib	_cairo_pixman_region_union	
9.7%	66.7%	libcairo.2.dylib	pixman_op	


A bit of analysis, now. As before the patch, most of the time is  
spent in gtk_tree_view_bin_expose.
If we have a closer look at the previous "hot spot", here's what we see:

Self	Total	Line		Code

		4240	      /* we *need* to set cell data on all cells before the  
call			
		4241	       * to _has_special_cell, else _has_special_cell() does  
not			
		4242	       * return a correct value.			
		4243	       */			
		4244	      for (list = (rtl ? g_list_last (tree_view->priv- 
>columns) : g_list_first (tree_view->priv->columns));			
		4245		   list;			
12.5%	0.0%	4246		   list = (rtl ? list->prev : list->next))			
		4247	        {			
28.1%	0.0%	4248		  GtkTreeViewColumn *column = list->data;			
3.1%	5.6%	4249		  gtk_tree_view_column_cell_set_cell_data (column,			
		4250							   tree_view->priv->model,			
		4251							   &iter,			
		4252							   GTK_RBNODE_FLAG_SET (node, GTK_RBNODE_IS_PARENT),			
		4253							   node->children?TRUE:FALSE);			
		4254	        }			


We spend between 3 and 4% of the time in  
gtk_tree_view_column_cell_set_cell_data, where we previously spent  
around 26% of the time. So Markku's patch definitely ironed out a  
performance bottleneck (congrats, I think this patch is a keeper.)

Now, let's try to figure out where the time goes. The call which  
occupies the time in gtk_tree_view_bin_expose is the call to  
gtk_default_paint_focus (which explains why the interface is  
responsive when not painting the focus row).

This leads us into the depths of cairo. Before we I go down that  
road, I'd like to have a better understanding of why the keyboard  
navigation is so slow when the mouse navigation is fine.

With Markku's patch, I think we're close to having a tree view  
capable of handling 5000 columns - the fact that we get good  
performance when using the mouse focus instead of keyboard focus  
gives me good hopes :)

Nicolas