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.lindg...@aol.com > <mailto:john.lindg...@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 > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
