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

[Mark <markg85 gmail com>]

On Sat, Nov 14, 2009 at 5:18 PM, Mark <markg85 gmail com> wrote:
> 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?
>

Are people still interested in this? since my school project that is
also about this is started now thus more progress will come here if
people are interested..