On Tue, Nov 11, 2014 at 3:50 AM, Dominik Vogt <vogt@xxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html