On Thu, Oct 10, 2019 at 12:14:13PM +0200, Martin Pieuchot wrote:
> On 10/10/19(Thu) 11:40, Stefan Sperling wrote:
> > On Thu, Oct 10, 2019 at 11:18:25AM +0200, Martin Pieuchot wrote:
> > > What I'm trying to point here is that this looks like a usual 'prefetch'
> > > case.  We just need to prefetch "enough" commits to have a nice user
> > > experience when displaying next commits.  Defining "enough" is the
> > > thought part as it depends on the speed of the machine.  Your approach
> > > seems to define "enough" as "everything" (o:
> > 
> > The problem with search is that we cannot tell when the next matching
> > commit will be found. Whatever fixed number we pick there will be a
> > search pattern which triggers a stall every time the 'n' key is hit.
> > If loading 4k commits is too aggressive, we could lower the value.
> 
> With your diff tog(1) loads 24k commits, not 4k.
> 
> My question is more, why does it load all the commits and not just 4k
> then 4k more later on (maybe when there's only 2k lefts to search)?

Ah, indeed. Because search is being retriggered as part of the main loop.
Asking for 100 commits per iteration seems like a more reasonable limit
and makes it stall less often during search for me (diff below).

> In my use case it is not always a screenfull ahead.  I see:
> 
> [1/48]
> press arrow down
> [2/48]
> press arrow down
> [48/116]
> press arrow down
> [96/116]
> press arrow down
> [116/116]
> press arrow down
> --> STALL
> [116/184]
> press arrow down
> [164/184]
> press arrow down
> [184/184]
> press arrow down
> --> STALL
> [184/252]
> ...patterns repeat

Where you write "--> STALL" I just see "loading..." on the screen
very very briefly.

I suspect your problem is somewhere else.
Why is loading just a couple of commits so slow that you can notice it?
How come it does not feel slow during initial startup?

Did you already try 'git repack -a'?


diff d59c0cb27bc304bc11f9b1094c6eb85f248c7c5f /home/stsp/src/got
blob - aad8017a1963e96977883c2dadfcef0fce8eac58
file + tog/tog.c
--- tog/tog.c
+++ tog/tog.c
@@ -1827,9 +1827,11 @@ search_next_log_view(struct tog_view *view)
 			 * Poke the log thread for more commits and return,
 			 * allowing the main loop to make progress. Search
 			 * will resume at s->search_entry once we come back.
+			 * Prefetch a certain number of commits to hopefully
+			 * avoid stalling every time the user hits the 'n' key.
 			 */
-			s->thread_args.commits_needed++;
-			return trigger_log_thread(1,
+			s->thread_args.commits_needed += 100;
+			return trigger_log_thread(0,
 			    &s->thread_args.commits_needed,
 			    &s->thread_args.log_complete,
 			    &s->thread_args.need_commits);