Steve,
Are you looking at the time it takes to show the window or the time
before the CPU usage drops to idle? GtkTreeView does a lot of work in
the background after the window appears.
-- John
On 12/15/2011 11:17 PM, Steve . wrote:
> John,
>
> I just ran your test on my thinkpadx61, It only t
On 12/15/2011 09:56 PM, Steve . wrote:
> John,
>
> I can't tell you this /will work/. More over this is how I'd first
> approach the problem (maybe I'm way off base here too)
>
> My initial thoughts are that the user can't see 100,000 items at once
> so there is no need to expect the widget to hand
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 exper
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 Gtk
Em 13/12/2011 10:05, escreveu:
> That's not the problem, I think. All modern systems will let you
> allocate at least ~1.5 gb before refusing malloc, no matter how much
> memory you have or what other processes are doing. The trick is
> keeping the working set of the processes within physical memo
