Thu, 22 Mar 2012 16:07:50 +0400 от Ibragimov Rinat <ibragimovrinat mail ru>:
Sorry for putting in, but that's the problem I mentioned earlier, in the beginning of January. It arises when there are many images in one directory. My test with 20000 images in one directory reveals that most of cpu time spent inside libglib and libgobject. There is some big-big cycle which forces generation of same thumbnails again and again.
Another numbers with gcov. I limited directory to 2000 images (3000 takes too long). _gth_file_list_update_next_thumb invoked 2006 times. 2000 times from thumbnail_job_ready_cb and 6 times from restart_thumb_update_cb. At least once per image in directory. And every time in runs cycle from first visible image in view to +N_CREATEAHEAD. Thus running 1967135 inner iterations. It's approximately 2000^2 / 2. As N_CREATEAHEAD hardcoded to 50000, such quadratic complexity will last to 50000 images in directory. Something gone wrong. Either _gth_file_list_update_next_thumb should update only one thumbnail at a time or it should be called only once. Thu, 22 Mar 2012 14:55:54 +0100 от Paolo Bacchilega <paolo bacchilega libero it>:
I tried this script and I still cannot see any performance issue, can you post the full callgrind report?
attached. I can send entire callgrind.out, if it's ok to send 670 kiB file to the list. -- Rinat
Attachment:
exclusive.txt
Description: Text document
Attachment:
inclusive.txt
Description: Text document