From: Martin Pieuchot <mpi@openbsd.org>
Subject: Re: tog log & got-read-pack on the fly:
To: gameoftrees@openbsd.org
Date: Thu, 10 Oct 2019 13:46:49 +0200

On 10/10/19(Thu) 12:29, Stefan Sperling wrote:
> [...] 
> I suspect your problem is somewhere else.

I'm just describing a use case where I have to wait for a tool :)

> Why is loading just a couple of commits so slow that you can notice it?

Because I'm impatient?  Because my machine is under load?  Because I'm
corrupted by tig(1)?

> How come it does not feel slow during initial startup?

It doesn't feel slow because the ncurses(3) display only appears when stuff
is already loaded.

Diff below makes tog(1) freeze as soon as it tries to go beyond the
first page.  Nothing seems to be fetched before that.  The top bar keeps
displaying:

commit ........................................ /sys [46/49] searching...

Pressing 'n' doesn't refresh the view.

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