Re: [gthumb-list] [PATCH][RFC] Reduce cpu usage wit h many images inone directory

[Ibragimov Rinat <ibragimovrinat mail ru>]

08 января 2012, 18:45 от Paolo Bacchilega <paolo bacchilega libero it>:
 
> This patch is very interesting, I've attached a new patch that stores 
> position+1 in the hash table instead of the position itself, this way 
> you can distinguish the case when the file is not found and when it is 
> in position 0.  The patch also uses the hash table each time there is a 
> need to search a file in an array, this way the quadratic complexity 
> should go away.
>
> I'll test the patch for some time before committing it, thank you.

Thaks for replying, I completely missed that 0 (==NULL) issue.
I tried your patch, but unfortunately it does not produce significant acceleration.
It seems most of cpu time spent somewhere inside glib. When I compiled gthumb
with -pg it showed that less than a second (of total ~600) spent inside gthumb code.
So that first patch (in gth-file-list.c) has greater effect, as it significantly decreases number of library 
calls.
As I said earlier I understand that it is not a reasonable solution, but can't offer anything better.

Additionally I faced another problem. When I try to run gthumb (from git) under valgrind's callgrind tool,
it crashes. The same build of gthumb itselft works well. 

$ valgrind --tool=callgrind gthumb/gthumb ~/temp/7/
==8072== Callgrind, a call-graph generating cache profiler
==8072== Copyright (C) 2002-2010, and GNU GPL'd, by Josef Weidendorfer et al.
==8072== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==8072== Command: gthumb/gthumb /home/rinat/temp/7/
==8072== 
==8072== For interactive control, run 'callgrind_control -h'.

(gthumb:8072): GLib-GObject-WARNING **: invalid cast from `GtkPaned' to `GthFileList'

** (gthumb:8072): CRITICAL **: gth_file_list_set_type: assertion `GTH_IS_FILE_LIST (file_list)' failed

(gthumb:8072): GLib-GObject-WARNING **: invalid cast from `GtkPaned' to `GthFileList'
==8072== 
==8072== Process terminating with default action of signal 11 (SIGSEGV)
==8072==  Access not within mapped region at address 0x384A039478
==8072==    at 0x4617C5: _gth_file_list_queue_op (in /home/rinat/temp/7/gthumb-git/gthumb/gthumb)
==8072==    by 0x44F176: pref_general_filter_changed (in /home/rinat/temp/7/gthumb-git/gthumb/gthumb)
==8072==    by 0x6AFE803: g_closure_invoke (gclosure.c:774)
==8072==    by 0x6B10789: signal_emit_unlocked_R (gsignal.c:3272)
==8072==    by 0x6B19E10: g_signal_emit_valist (gsignal.c:3003)
==8072==    by 0x6B19FB1: g_signal_emit (gsignal.c:3060)
==8072==    by 0x57B6130: g_settings_real_change_event (gsettings.c:277)
==8072==    by 0xAF487BB: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.5.0.10)
==8072==    by 0xAF48236: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.5.0.10)
==8072==    by 0x6AFECC6: g_cclosure_marshal_generic (gclosure.c:1147)
==8072==    by 0x6AFE803: g_closure_invoke (gclosure.c:774)
==8072==    by 0x6B105BE: signal_emit_unlocked_R (gsignal.c:3310)
==8072==  If you believe this happened as a result of a stack
==8072==  overflow in your program's main thread (unlikely but
==8072==  possible), you can try to increase the size of the
==8072==  main thread stack using the --main-stacksize= flag.
==8072==  The main thread stack size used in this run was 8388608.
==8072== 
==8072== Events    : Ir
==8072== Collected : 476855837
==8072== 
==8072== I   refs:      476,855,837