Re: ideas on improving the performance of gtk_tree_view

["Kalle Vahlman" <kalle vahlman gmail com>]

2007/3/22, Nicolas Setton <setton adacore com>:
[snip]
> So, it seems that we spend most of our time traversing the list of
> columns. Note that this explains why a tree of 5000 columns x 50 rows
> has such bad performance compared to a tree of 50 columns x 5000 rows.

Your test program is also creating 4950 cellrenderers more in that
case, while the extra rows are "for free" in that sense (ie. same
amount of data items stored, but no extra cellrenderers). See below
for more on this.

> First suggestion: we'd be better off in this subprogram if the data
> was implemented as an array instead of as a linked list.

I guess this could be valid in any case...

> Let's turn now to comment B). Why is gtk_tree_view_bin_expose calling
> gtk_tree_view_column_cell_set_cell_data ?
[snap]
> I'm not familiar with this area yet, so I'm puzzled: is the call to
> gtk_tree_view_column_cell_set_cell_data really needed for the
> purposes of gtk_tree_view_bin_expose, or is it just needed for the
> call to gtk_tree_view_has_special_cell?

It _is_ really needed for expose, since GtkCellRenderers are not tied
to the data it's rendering:

"
The primary use of a GtkCellRenderer is for drawing a certain
graphical elements on a GdkDrawable. Typically, one cell renderer is
used to draw many cells on the screen. To this extent, it isn't
expected that a CellRenderer keep any permanent state around. Instead,
any state is set just prior to use using GObjects property system.
Then, the cell is measured using gtk_cell_renderer_get_size().
Finally, the cell is rendered in the correct location using
gtk_cell_renderer_render().
"
http://developer.gnome.org/doc/API/2.0/gtk/GtkCellRenderer.html#id3190590

> In any case, I suggest we cache this - probably there is no need to
> do it in every expose call, only after the model data has changed.

...so it isn't really feasible to cache the renderer state. The good
news learned from the above is that if you simply move the renderer
creation outside the for loop, you'll get the same functionality but
without 4999 extra cellrenderers in memory :)

> To sum up (thanks for reading me), would you accept a patch along
> those lines?

I let Kris and others comment on the array thing, but it would be
interesting to re-measure and see how much the 4999 cellrenderers were
affecting the performance (not much I guess, but it should use a fair
amount less memory then).

Anyway, nice test case to hack on :)

--
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi