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.
Or we could adapt the value dynamically, e.g. based on the ratio of
matches vs. non-matches we're seeing as the user progresses through
search results.
But there will be cases where any heuristic gets it wrong.

> 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.

Check the commit counter at the top. When I start tog in a fullscreen
terminal on my machine, I intially see "[1/34]" with 33 commits displayed.
When I move to commit 34 the numbers change to "[34/55]". Now the display
starts scrolling as I move through, and when I reach commit 55, which is
displayed at the bottom of the screen, the numbers change to "[55/76]".
So when scrolling downwards, the amount of loaded commits is always a
screenfull ahead of what is being displayed.

I don't see any noticable stalls when scrolling through history.

> That said, I'd suggest to test this diff on a miod-grade machine, to see
> if it isn't too slow :)

I agree we need to avoid causing trouble on slow machines. But we
should not make fast machines much slower than they could be either.