> 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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
