reftable/stack: avoid reloading the stack when already locked

When making modifications to the reftable stack, the stack obtains a
lock to the list file and removes the lock after the commit phase. Since
most operations reload the stack to ensure we have the latest state, any
branched operation during the locked phase could trigger a state reload.

To prevent data loss due to concurrent writes, state reload is necessary
right after obtaining the lock. But any reloads after that are just a
no-op. Now that the struct has access to the lock file status, simply
skip reloading if the lock is present.

Benchmarking with a fixed, non-symbolic target OID in the 'refs/tags/'
namespace (since it triggers a stack reload when checking if reflog
exists for the given tag name), shows a consistent 15-20% improvement
with these patches:

  refcount   master     patch     speedup
  --------   -------    -------   -------
  2,000       18.5 ms    16.6 ms   1.11x
  20,000     120.7 ms   102.8 ms   1.17x
  50,000     296.5 ms   247.1 ms   1.20x

We can also see the improvements in the number of syscall counts. On
master, the number of calls to `newfstatat()` grows linearly with the
number of refs created. With this patch, the number is now a constant:

  refcount   master   patch
  --------   ------   ------
  1,000      1,059       55
  5,000      5,059       55
  10,000     10,059      55
  20,000     20,059      55

Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

0 files changed, 0 insertions, 0 deletions