Thread (1 message) 1 message, 1 author, 2016-06-15

Re: tig: Improving startup time and interactivity

From: Jonas Fonseca <hidden>
Date: 2016-06-15 23:02:55

On Tue, Nov 11, 2014 at 3:50 AM, Dominik Vogt [off-list ref] wrote:
Hi Jonas,
HI Dominik,

Good to hear from you.
working on a relatively old machine with a crypted disk, there are
really two performance problems with tig on large repos like gcc
or the Linux kernel.  I wonder what would be necessary to improve
these two problems:

 1) Firing up tig for the first time in the kernel repo, the screen
    goes blank for about a minute.  After that it comes up
    quickly.  This is probably caused by decrypting lots of
    on-disk-objects.
You are not alone at reporting this problem. The main reason is that
when the revision graph is enabled, tig automatically passes
--topo-order to git-log. This commit order seems to cause quite a slow
down before the first commits are available in the output in the Linux
kernel repo, I assume, due to its many merges.

I recently added an option to disable the automatic forcing of
topological commit order. So assuming you are using tig from current
master, you can do this using `set main-view-commit-title-graph =
no-topo`, but I will probably move this setting to another option
before the next release (so if it breaks take a look at the NEWS
file). Alternatively you can disable the revision graph completely
using `set main-view-commit-title-graph = no`.

Before the next commit I plan to also investigate whether tig can
first load a screen full of commits without --topo-order and then
restart git-log, so the main view has content faster.
 2) When I cherry pick commits inside tig, it reloads the whole
    commit history of the active branch before tig accepts new
    commands.
This should should be able to disable this behaviour using `set
refresh-mode = manual` if you don't want tig to automatically reload
the view.
I guess both issues are caused by tig reading the whole commit
history before user input is allowed.  Is there a way to do that
in the background, or interrupt loading when the user presses a
key, or to load the history in small chunks?
The loading should already happen while also accepting user input
(modulo any bugs).
After all, you're
usually interested only in the last 100 commits or so, and there's
no need to block the UI while loading the rest.
True. Well,  The only part of the loading that is blocking is the
.git/index refreshing that takes place when display of work tree
changes is enabled in the main view (when `set show-changes = yes`).

I will review this again.
Could you point me to the right source file?  I'm not used to the
sources split into multiple files yet.  :-)
Try: tig grep main_open
Ciao
Have a great day.

-- 
Jonas Fonseca
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help