2007/3/22, Nicolas Setton <[EMAIL PROTECTED]>: [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, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
