On Fri, Jan 28, 2022 at 12:13:43PM -0700, Ted Bullock wrote:
> Thanks, this is the kind of workflow answer I was looking for.

My pleasure!

> Out of curiosity has anyone looked to see what mechanisms git is using for
> these operations? For the /usr/src tree git seems to be able run a status
> command over nfs in under a minute on the old sparc64 system I've been
> testing on whereas got takes around 11 to complete its own status command on
> this machine.
> 
> $ time got status
>    10m44.59s real     0m23.81s user     2m11.92s system

Both systems are quite different by design, and Got is generally slower.

Last time I profiled 'got status' the bottleneck were stat(2) calls
and I did not see an obvious way to improve performance. (See the
README file in Got's source tree for more information about profiling).

Our use of unveil(2) makes performance of some syscalls a bit worse,
which probably does not help. On my amd64 laptop in /usr/src, I see:

$ for i in 1 2 3; do time got status >/dev/null; done
    0m03.19s real     0m01.07s user     0m02.08s system
    0m03.00s real     0m01.10s user     0m01.94s system
    0m03.17s real     0m00.92s user     0m02.24s system

And with apply_unveil() in got/got.c stubbed out, I get this:

$ for i in 1 2 3; do time got status >/dev/null; done
    0m02.27s real     0m00.97s user     0m01.30s system
    0m02.26s real     0m01.04s user     0m01.20s system
    0m02.27s real     0m01.05s user     0m01.22s system

This does not account for the full difference you see on NFS, so there
could be ways to improve performance. Our DT_UNKNOWN workaround causes
additional stat calls, so perhaps adding the -l mount option will help
a bit?

It would be interesting to learn why Git is so much faster, but I have not
looked in detail. There is a lot of complicated Git code to read if you
want to find out. I won't spend time on it myself because there are other
areas which are in more dire need of improvement.