Open maximbaz opened 4 years ago
Improving startup performance is certainly something that can be done.
Personally, I find startup fast enough, as I usually start vimiv
and then run through the library for considerable time. Opening just one image does not happen frequently. A definition of "fast enough" would be great, and any further information on usecases which are limited by startup performance could also help. We could, e.g. lazier load some of the widgets, which may not be used at every start.
Note for self: running a profiler on the current startup shows:
29086 function calls (28939 primitive calls) in 0.159 seconds
Ordered by: cumulative time
List reduced from 936 to 15 due to restriction <15>
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 0.160 0.160 ~/Coding/VimivQt/vimiv/startup.py:37(main)
1 0.000 0.000 0.121 0.121 ~/Coding/VimivQt/vimiv/startup.py:73(setup_post_app)
18/5 0.000 0.000 0.082 0.016 ~/Coding/VimivQt/vimiv/api/objreg.py:49(inside)
1 0.000 0.000 0.049 0.049 ~/Coding/VimivQt/vimiv/startup.py:119(init_ui)
1 0.000 0.000 0.037 0.037 ~/Coding/VimivQt/vimiv/imutils/__init__.py:47(init)
1 0.000 0.000 0.035 0.035 ~/Coding/VimivQt/vimiv/gui/mainwindow.py:39(__init__)
1 0.000 0.000 0.029 0.029 ~/Coding/VimivQt/vimiv/imutils/_file_handler.py:63(__init__)
1 0.000 0.000 0.028 0.028 ~/Coding/VimivQt/vimiv/imutils/immanipulate.py:364(__init__)
11 0.026 0.002 0.026 0.002 {built-in method setText}
1 0.000 0.000 0.025 0.025 ~/Coding/VimivQt/vimiv/imutils/immanipulate.py:120(focus)
1 0.000 0.000 0.024 0.024 ~/Coding/VimivQt/vimiv/startup.py:50(setup_pre_app)
43/39 0.000 0.000 0.022 0.001 {method 'emit' of 'PyQt5.QtCore.pyqtBoundSignal' objects}
159 0.000 0.000 0.020 0.000 /usr/lib/python3.8/logging/__init__.py:1553(_log)
6 0.018 0.003 0.019 0.003 {built-in method addWidget}
1 0.000 0.000 0.019 0.019 ~/Coding/VimivQt/vimiv/startup.py:107(init_paths)
29086 function calls (28939 primitive calls) in 0.159 seconds
Ordered by: internal time
List reduced from 936 to 15 due to restriction <15>
ncalls tottime percall cumtime percall filename:lineno(function)
11 0.026 0.002 0.026 0.002 {built-in method setText}
6 0.018 0.003 0.019 0.003 {built-in method addWidget}
1 0.012 0.012 0.012 0.012 {fromImageReader}
55 0.012 0.000 0.012 0.000 {method 'read' of '_io.BufferedReader' objects}
1 0.011 0.011 0.013 0.013 {function MainWindow.show at 0x7f226f532280}
1 0.010 0.010 0.010 0.010 ~/Coding/VimivQt/vimiv/app.py:24(__init__)
160 0.009 0.000 0.009 0.000 {method 'flush' of '_io.TextIOWrapper' objects}
2 0.006 0.003 0.006 0.003 {built-in method insertTab}
4 0.005 0.001 0.005 0.001 {built-in method fcntl.fcntl}
43 0.004 0.000 0.004 0.000 {built-in method setSourceModel}
11 0.003 0.000 0.003 0.000 {built-in method setStyleSheet}
5 0.002 0.000 0.003 0.001 ~/Coding/VimivQt/vimiv/imutils/immanipulate.py:70(__init__)
1 0.002 0.002 0.002 0.002 {built-in method _imp.create_dynamic}
136 0.002 0.000 0.002 0.000 {method 'connect' of 'PyQt5.QtCore.pyqtBoundSignal' objects}
159 0.001 0.000 0.003 0.000 /usr/lib/python3.8/logging/__init__.py:284(__init__)
Personally, I was considering to make vimiv
my default image previewer app that I would integrate with file managers. I understand it's a different use-case as opposed to opening vimiv
to browse through the library, here the goal is to open a single image alone, but open it fast. Maybe in cases when vimiv
is being opened with an image argument, make the image appear as fast as possible, and let the library load asynchronously while the image is already drawn...
Right now I ended up using sxiv
for image preview and vimiv
for longer image browsing, but it would be really nice to use a single tool for both scenarios.
Some tweaks were made in #126. There is certainly more to do, but I hope this already helps a bit :)
I tested and I already feel significant improvement on the latest master
, thank you for #126!
Shouldn't this issue be closed?
I still feel like there is more that could be done, although I currently don't have any direct ideas for a significant improvement independent of #363.
I've seen https://github.com/karlch/vimiv/issues/67 and I must say this is still the case in the QT port.
The goal is not to compete with
feh
on who's faster, the goal is to make the startup fast enough.Is this something on your mind to improve?