Re: GtkTreeView very slow for large lists

[Tristan Van Berkom <tvb gnome org>]

On Fri, Dec 16, 2011 at 10:32 PM, John Lindgren <john lindgren aol com> wrote:
> Steve,
>
> I use the "time" shell command and wait for my CPU meter to drop back to
> idle before quitting the test program, giving something like this:
>
>    time ./list-test
>
>    real    0m31.719s
>    user    0m29.168s
>    sys    0m0.023s

GtkTreeView should definitely be usable with millions of rows in
the data model.

Remember that "should" is a word with many implications, things
that GtkTreeView should be doing include avoiding requesting the
size for every row in the model.

And of course your GtkTreeModel implementation should not
load all actual data but instead implement the interface in a way
that data is only loaded on demand (one should be able to tell
how large, how many rows without actually pulling the data for
every row).

A good starting point would be to open gtktreeview.c and start
figuring ways to avoid the loop which currently itterates over the
entire data store and finds the perfect size of the treeview.

A good technique for this would be to synchronously request
the size for all visible rows (which is currently done), plus request
the size of 1 or 2 visible page sizes of previous and following rows.

After that one might check the width and height requests of only
one out of every 10 thousand following rows (assuming a 5 million
row treeview or such, make a reasonable calculation), and estimate
the total size of the treeview height/width based on that.

The estimated non-visible size of the treeview is really only useful
for driving the adjustment page size and current location used for
the scrollbars.

In terms of responding to height-for-width requests, it's only
really important to report true height-for-width until you reach
gdk_screen_height(), and only in order to support treeviews which
are not placed into scrolled windows. For treeviews placed into
scrolled windows (if it were the only use case), the treeview could
simply report a height request of 1 pixel and not calculate anything
synchronously at all.

Thankyou for looking into GtkTreeView performance ;-)

Kind Regards,
        -Tristan

> -- John
>
> On 12/16/2011 12:24 AM, Steve . wrote:
> > John,
> >
> > Time to pop the window and populate. The cpu use meter (kinda real
> > time, 500ms sample) shows between 500ms ans 1 second.
> >
> > Do you have a preferred timer method, if so i could throw a snip
> > before gtk init, and maybe in the main loop idle?  Now that i'm
> > thinking about it, what is the best way to measure gtk activity?
> >
> > Suggestions?
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list