Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.

[Mark <markg85 gmail com>]

On Mon, Oct 5, 2009 at 3:05 PM, Mark <markg85 gmail com> wrote:
> On Mon, Oct 5, 2009 at 3:26 PM, Dr. Michael J. Chudobiak
> <mjc avtechpulse com> wrote:
>> On 10/03/2009 02:08 PM, Mark wrote:
>>>>
>>>> So what's the conclusion? The existing Nautilus code is OK, except that
>>>> it
>>>> should be threaded?
>>>
>>> That sounds like a good conclusion for now but are we going to do
>>> something with it?
>>
>> I'm not a Nautilus developer, but I'd guess that a benchmarked patch against
>> Nautilus would be appreciated...
>>
>> - Mike
>>
>
> That will, in time, come.
> I don't have the time right now or the coming weeks to do that but i
> will make something somewhere late this month early next month
>
> I'm also kinda afraid that speeding up the thumbnailing progress isn't
> going to speed it up visually because of GTK... right now it seems
> nautilus is redrawing the window with every change while that might be
> faster if it only updates once every second.. i might be wrong about
> that but it's just my visual observation.
>

I have a new benchmark.
look at it here: http://img252.imageshack.us/img252/8265/graphs.png

What i do find extremely odd is the difference of
gdk_pixbuf_new_from_file_at_scale from last time and from now (and i
didn't change the glib benchmark so it's just.. faster somehow)
Anyway, the new gdk_pixbuf_new_from_file_at_scale benchmark is at 43
seconds. Now the interesting stuff. I made the same benchmark with
pure Qt c++ code. No other things. At first the Qt bench was a lot
slower but as i went on and tried other things it ended up beating the
glib benchmark! the thumbnail quality is exactly the same between both
the Qt en the Glib benchmarks. If you want the code for the Qt
benchmark look here: http://codepad.org/QuUGHmtr

Both benchmarks used thread queues.

Another odd thing is that with the last benchmarks (with 70 seconds
for the same bench)  there was roughly 40% cpu usage if memory serves
me well.. Now it was close to 100% (more like 92%) for the Glib and Qt
benchmarks..
As for the timings.. it certainly wasn't in memory since i did: sync;
echo 3 > /proc/sys/vm/drop_caches between every benchmark. Skipping
that gave me a time of just 16 seconds!

The files are all still the same.. perhaps some packages (like glib
and the linux kernel) got updated that might (?) have fixed something
somewhere?