Re: Poor performance with large ListStore/TreeView

[Christoph Reiter <reiter christoph gmail com>]

2014/1/14 Jonathan Ballet <jon multani info>:
> I'm a bit out of idea on what else I can try. I can provide more
> information about those numbers, especially if you need some profiling
> data. I'm all in for more PyGObject performances too, although I don't
> where to start in the code base, but I'm willing to try stuff.

In Quod Libet we use an optimized single column ListStore subclass [0]
with a few fast paths and hacks to remove the override overhead. We
only use cell_data_func and do the formatting and detecting the
current song in there. I think append_many() is about 3-4 times faster
than Gtk.ListStore.append, so still not as fast as the old one (or
reverse() + insert(0,x), which was even faster in pygtk), but more
bearable.

Since I'm the sole copyright owner of that file I could multi-license
it if needed.

Regarding scrolling: In addition to caching for formatting, I also
save the last result for each cell_data_func and don't update the cell
renderer if there is no new data. Depending on the type of formatting
you do, you can skip the formatting or the set_property() call. The
cell renderer happily draws the same thing in a different row then.
Say, multiple redraws of the same cell, or it's an album name column
where many entries are the same. This helped a bit in GTK+2 times at
least.

regards

[0] https://bitbucket.org/lazka/quodlibet/src/default/quodlibet/quodlibet/qltk/models.py