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)?

> > In the case of history scrolling, "enough" might be the number of
> > commits displayable at once, or twice that quantity.  Maybe that's good
> > enough for search as well, or we can prefetch 4K commits... whatever.
> 
> Observing prefetching behaviour during scrolling is easy.
> [...] 
> So when scrolling downwards, the amount of loaded commits is always a
> screenfull ahead of what is being displayed.

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

Now if I press 'arrow down' multiple times very fast, because I want to
skip 6 months of commits, I experience the stall a lot :o)