Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
- From: Mark <markg85 gmail com>
- To: Ross Burton <ross burtonini com>
- Cc: gtk-devel-list gnome org, David Zeuthen <david fubar dk>, Alexander Larsson <alexl redhat com>
- Subject: Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
- Date: Thu, 1 Oct 2009 00:12:55 +0200
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: http://burtonini.com
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
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
thread)
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:
http://library.gnome.org/devel/gnome-desktop/stable/gnome-desktop-Miscellaneous-Thumbnail-Functions.html
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: http://codepad.org/8NiBOhMY
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]