The better approach would likely be to move away from the single lock and maybe use the digest[:2]-based paths to keep hit/miss stats for each of the 256 buckets. This reduces the contention in the (frequent) update path, at the expense of the (infrequent) read and clear paths having to enumerate the folders.
I was looking into https://github.com/matus-chochlik/ctcache/issues/36 again as it showed up in our CI build system recently. This PR has a minor tweak.
The better approach would likely be to move away from the single lock and maybe use the
digest[:2]
-based paths to keep hit/miss stats for each of the 256 buckets. This reduces the contention in the (frequent) update path, at the expense of the (infrequent)read
andclear
paths having to enumerate the folders.