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

On Wed, Sep 30, 2009 at 8:13 PM, Ross Burton <ross burtonini com> wrote:
> On Wed, 2009-09-30 at 13:06 -0400, David Zeuthen wrote:
>> No, it's actually a great example.
>> The way it works is that a GVfs backend can set the preview::icon file
>> attribute (which is a GIcon) [1] to whatever it wants. In GVfs we have a
>> class, GVfsIcon, that implements GLoadableIcon and GIcon. When clients
>> read preview::icon, then the loading of the returned icon is directed
>> back to the backend via the open_icon_for_read() VFunc on the
>> GVfsBackend class. The backend can then use any API it wants to
>> get/create the thumbnail. It is completely unrelated to the file in
>> question.
> I take it back, that is neat. :)
> Ross
> --
> Ross Burton                                 mail: ross burtonini com
>                                          jabber: ross burtonini com
>                                           www:
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org

I have a little more realistic benchmarks now. I did the sync; echo 3
> /proc/sys/vm/drop_caches after each benchmark run (didn't do it
before) and now my results are close to the ones from Alexander. Just
for fun i also added a threaded benchmark where i didn't do sync; echo
3 > /proc/sys/vm/drop_caches and note the extreme difference.

While running the threaded benchmark i had ~40% io wait in iostat (not
tested with other benchmarks) so unlike i thought previously my hdd is
indeed the bottlenech (which was my first thought when i started this
The numbers:

# gdk_pixbuf_scale_simple
real	2m58.899s
user	2m18.201s
sys	0m1.667s

# gnome_desktop_thumbnail_scale_down_pixbuf / gnome_thumbnail_scale_down_pixbuf
real	2m53.911s
user	2m13.648s
sys	0m1.690s

# gdk_pixbuf_new_from_file_at_scale
real	1m58.988s
user	1m13.942s
sys	0m1.480s

# gdk_pixbuf_new_from_file_at_scale with 4 threads
real	1m10.000s
user	1m14.445s
sys	0m2.377s

# gdk_pixbuf_new_from_file_at_scale with 4 threads and cached files by
the last benchmark.
real	0m21.478s
user	1m14.625s
sys	0m1.743s

I did notice a bug here: gnome_desktop_thumbnail_scale_down_pixbuf /
gnome_thumbnail_scale_down_pixbuf the docs here:
name it gnome_desktop_thumbnail_scale_down_pixbuf but the actual
header file: #include <libgnomeui/gnome-thumbnail.h> names it:
gnome_thumbnail_scale_down_pixbuf (without the _desktop) and that took
me a few minutes before i spotted it.

In the end the function gnome_thumbnail_scale_down_pixbuf was indeed
faster (just a few seconds, but faster) then gdk_pixbuf_scale_simple.
I think a raid setup would really show some different numbers here ^_^

O btw, i tried to make a OpenMP version as well but couldn't get it
done with that queue i'm using.. could someone else try that please?
And for the current benchmarking code, i fixed the bug alexander said
and the gnome_thumbnail_scale_down_pixbuf is now with optimize stuff
(i hope).
grab it here:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]