Skip to content

Cache quota shouldn't be computed until we know we need to write to the cache

Summary

Currently cache cas initilization calculates the cache quota. This information is only needed when we will be writing to the cache, and as such should not be calculated until the last possible moment since it is expensive to calculate.

For example. on Windows WSL, it could increase bst show time to element load by 10-20 seconds, when the rest of the operations in bst show would take roulghy 0.2s.

Steps to reproduce

  • Have many things in your cache
  • bst show, consider the time before the "loading element" message.

What is the current bug behavior?

Cas quota is computed unneccessarily for read only operations on the cache.

For example, the following commands don't need to write anything and we could therefore save 20s on their invocation:

  • bst show
  • bst workspace *
  • bst shell
  • bst push
  • bst source {checkout,push}
  • bst checkout
  • bst artifact log
  • bst artifact delete (maybe? arguably)

What is the expected correct behavior?

Instantaneous startup, we don't care about the cache size in those scenarios, we shouldn't be losing time computing them.

Relevant logs and/or screenshots

Timings from the import of "bst" to the moment in code when this was called.

cli: function entry 0.19205307960510254
app: context loaded 0.19537138938903809
app: platform instantiated 0.20264530181884766
app: logger ready 0.20321416854858398
base cache: init 0.20326685905456543
base cache: cas cache initialized 0.20374846458435059
base cache: cas quota set 11.165070295333862 <<< CACHE QUOTA COMPUTED
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information