Re: GtkTreeView very slow for large lists

[John Lindgren <john lindgren aol com>]

Hi Steve,

I'm not sure that I understand.  Are you saying that we should assume
that the user wants access to only part of the playlist and somehow try
to predict what part?  This doesn't sound like a good solution to me.

-- John

On 12/15/2011 08:33 PM, Steve . wrote:
> John,
>
> I have no experience on such large lists so I may be speaking out of
> context here. But have you considered using your analysis to partition
> the list in to smaller, more use able chunks. Perhaps implement a look
> ahead, look behind buffer. When the current list selection is within
> delta, update the list. 
>
> 2011/12/15 John Lindgren <john lindgren aol com
> <mailto:john lindgren aol com>>
>
>     Hi,
>
>     I am the lead developer of Audacious (a GTK+ based music player).
>     Lately I have been trying to improve the performance with large
>     playlists (i.e. on the order of 100,000 entries).  The one remaining
>     problem spot seems to be GtkTreeView.  I am attaching a simple test
>     program that creates a GtkTreeView with 3 columns and 100,000 rows.
>     With GTK+ 3.2.2, the program uses 29 seconds of CPU time before
>     reaching
>     idle, on a 2 GHz Core 2 Duo.  (GTK+ 2.24.8 is considerably better,
>     at 10
>     seconds, but still too slow for practical use.)  Is there any way that
>     GtkTreeView can be made usable for such long lists?
>
>     -- John Lindgren