karlch/vimiv

slow start

Opened this issue · 1 comments

it takes considerable time for vimiv to initiate and display its window - even when asked to only display a single image.

$ time vimiv testimage.jpg
1,10s user 1,04s system 72% cpu 2,938 total

now the same with feh and display:

$ time feh testimage.jpg
0,01s user 0,00s system 5% cpu 0,211 total

$ time display testimage.jpg
0,02s user 0,01s system 7% cpu 0,442 total

it seems like vimiv is checking many files in my home library even if it does not use them later on.

$ strace -c -f vimiv testimage.jpg
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 67,07   29,248022       43266       676        22 futex
 13,41    5,849263       11769       497           poll
 13,38    5,835320       31204       187           select
  3,99    1,741821           8    213468       609 read
  1,80    0,786876           4    161085           gettimeofday

and feh:

$ feh -c -f feh testimage.jpg
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 24,50    0,001105           6       170       120 recvmsg
 16,36    0,000738           6       119           read
  7,69    0,000347          24        14           select
  7,47    0,000337           2       132           mmap
  6,76    0,000305           2       112           mprotect

do you have an idea what could be causing this? thank you.

[Version]       vimiv version 0.9.2.dev0
[Python]        3.6.6
[GTK]           3.22.30

If you only pass a single image to vimiv, it will still check the current directory for other images and open them all. The idea behind this is to open the complete image album when starting vimiv from a file manager, e.g. opening all holiday pictures when clicking on one. This certainly slows startup considerably.

Additionally vimiv has to load a bunch of GTK stuff via which also takes more time than the image viewers which do not depend on larger libraries.

So there could be an option to stop reading other files and only populate e.g. the library on demand, but startup would still not be competitive to the other image viewers. As this also was never intended to be the case, I am unsure if it would make sense to add this.

If added, it would be added to the QT port I started working on a while ago. Unfortunatley I am currently completely busy finalizing me thesis and won't be able to work on this until maybe mid-October. Sorry and hope this helps anyway! :)