Re: tig: Improving startup time and interactivity
Jonas Fonseca
2014-11-12 14:35:38 UTC
On Tue, Nov 11, 2014 at 3:50 AM, Dominik Vogt <> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at