Re: GtkTreeView: inserting rows faster.

[Peter Zelezny <pzel dodo com au>]

On 23 Mar 2003 04:46:23 -0500
Jonathan Blandford <jrb redhat com> wrote:

> > I've been trying to improve the performance of inserting new rows
> > into a GtkTreeView. The performance is somewhat lacking. I am calling
> > gtk_list_store_insert_after(), to try to avoid linear searches through
> > existing rows, but it's not having the desired effect.
> 
> I would be surprised if that's particularly slow.  Have you done any
> timings or profiling?

Unfortunately I don't have gtk libs compiled with -pg.


> Also, it is (not surprisingly) slower when you
> have a listener such as a GtkTreeView.

Yes, it's got a GtkTreeView displaying it. Looks like I was on the wrong
track with GtkListStore, the problem is somewhere in the gui code. If you
want to see it for yourself, probably the easiest way is to compile xchat
2.0.x, login to a large channel (~500 users, try #debian on freenode),
then type:

/timer -repeat 0 1 recv :nick!user host com JOIN :#debian
/timer -repeat 0 1 recv :nick!user host com PART :#debian

This simulates one insert/delete once per second, and already it's creating
quite a heavy load. I've noticed that it re-draws the userlist once
incorrectly, then correctly. Something like this:

.------.------------.
| Icon | Text       |
)------+------------(
| N*ck name         |
| Nickname 2        |
`-------------------'

Then it redraws:
.------.------------.
| Icon | Text       |
)------+------------(
|  *     Nick name  |
|        Nickname 2 |
`-------------------'

It does these two redraws for every 1 row inserted, you can see it
flicker. Note, some rows don't have an Icon (pixbuf passed in as
NULL, this might have something to do with it).

This happens even when the newly inserted row is not visible on the 
current page.

Admittadly, I have an old GTK (2.0.6 from RH8), but I've had reports
from people of the high cpu load on 2.2.1 aswell.

The current calls that cause it are only:

gtk_list_store_insert_after and
gtk_list_store_set.


> It doesn't.  This code is incredibly complicated, and cannot be
> described in a paragraph.  It does measure all rows at some point
> (mostly in an idle.)

What does it measure, text extents?


> > That's about I can see that could potentially be improved, from a quick
> > scan through the source. I'd like to hear some comments from people more
> > familiar with the code.
> 
> There is definitely room for speeding up this code, but I don't think
> any of these are worthwhile.

You're right, the problem I'm having isn't in GtkListStore.


> > Ideally, it should be possible to insert rows in constant time when
> > calling gtk_list_store_insert_(after/before). Is it achievable?
> 
> Insert before is not without adding a back pointer.  Also, we need to
> know the location of rows when we emit the signal.  This does require
> the walking of the list, but I feel this is prolly fast -- especially as
> we special case the last row (which is reasonably common.)  We might be
> able to do a few more special cases, but I'd really like to make sure
> this is slow first.

Something in the idle timeout (incremental reflow?) is causing undue
redraws or cpu usage. If I insert 500 rows in a loop, it doesn't cause
any more of a cpu hit than inserting 1 row. It's got something to do
with the icons in Column-0, because I can't reproduce it with a flat
1 column list.


-- 
Peter Zelezny.