From: Stefan Sperling <stsp@stsp.name>
Subject: Re: tog log & got-read-pack on the fly:
To: Martin Pieuchot <mpi@openbsd.org>, gameoftrees@openbsd.org
Date: Thu, 10 Oct 2019 12:47:51 +0200

On Thu, Oct 10, 2019 at 12:29:28PM +0200, Stefan Sperling wrote:
> 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?

One possibility is that your pack file contains delta chains that
are very deep, which makes got-read-pack consume a lot of CPU while
reading and applying deltas. Allowing got-read-pack to cache delta
objets might speed things up because, currently, delta objects are
re-read from disk upon every access to an object that has deltas.

Such problems can disappear after 'git repack -a' because it all
depends on how deltas are constructed by heuristics during packing.

This is a known issue, and there's an item for this in got/TODO where
an instance of this was observed on a massive src.git commit. Though
the problem there was related to access to blob objects, not to the
commit itself, and 'tog log' will never read blobs.

- fix 'got log -l1 -c fb4d85023675bc7da402da96b2bb84fd12905dbf -p';
  this command runs too slow in got-read-pack
  (maybe let got-read-pack cache ref/offset delta objects in object_cache.c?)
  commit fb4d85023675bc7da402da96b2bb84fd12905dbf is:
      from: jsg <jsg@openbsd.org>
      date: Wed May 22 00:40:06 2019 UTC
      "add amdgpu from linux 4.19.44 for recent AMD Radeon parts"

To confirm where got-read-pack is wasting time, you can build it in
profile mode like this:

	cd libexec/got-read-pack
	make clean
	make PROFILE=1
	make install

Now run tog, and then run gprof on the resulting gmon.out file.