More speedup via mtime-base caching.

[jaraco]

Extension of #274.

[jaraco]

In an attempt to troubleshoot, I added the following patch:

importlib_metadata fs-cache-v2 $ git diff -- importlib_metadata
diff --git a/importlib_metadata/__init__.py b/importlib_metadata/__init__.py
index 349de2e..f16d516 100644
--- a/importlib_metadata/__init__.py
+++ b/importlib_metadata/__init__.py
@@ -603,6 +603,7 @@ class FastPath:
 
     @functools.lru_cache()  # type: ignore
     def __new__(cls, root):
+        print("New FastPath for", root)
         return super().__new__(cls)
 
     def __init__(self, root):
@@ -636,6 +637,7 @@ class FastPath:
 
     @functools.lru_cache()
     def lookup(self, mtime):
+        print(self.lookup.cache_info())
         return Lookup(self)

And then running the cache test, it emits output like this:

perf run-test: commands[1] | python -m timeit -s 'import importlib_metadata; importlib_metadata.distribution("ipython")' -- 'importlib_metadata.distribution("ipython")'
New FastPath for .
CacheInfo(hits=0, misses=1, maxsize=128, currsize=0)
New FastPath for /Users/jaraco/code/public/importlib_metadata
CacheInfo(hits=0, misses=2, maxsize=128, currsize=1)
New FastPath for /Library/Frameworks/Python.framework/Versions/3.9/lib/python39.zip
CacheInfo(hits=0, misses=1, maxsize=128, currsize=0)
New FastPath for /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9
CacheInfo(hits=0, misses=2, maxsize=128, currsize=1)
New FastPath for /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload
CacheInfo(hits=0, misses=3, maxsize=128, currsize=2)
New FastPath for /Users/jaraco/code/public/importlib_metadata/.tox/perf/lib/python3.9/site-packages
CacheInfo(hits=0, misses=4, maxsize=128, currsize=3)
CacheInfo(hits=0, misses=5, maxsize=128, currsize=4)
CacheInfo(hits=0, misses=6, maxsize=128, currsize=5)
CacheInfo(hits=0, misses=1, maxsize=128, currsize=0)
CacheInfo(hits=0, misses=2, maxsize=128, currsize=1)
CacheInfo(hits=0, misses=3, maxsize=128, currsize=2)
CacheInfo(hits=0, misses=4, maxsize=128, currsize=3)
CacheInfo(hits=0, misses=5, maxsize=128, currsize=4)
CacheInfo(hits=0, misses=6, maxsize=128, currsize=5)
CacheInfo(hits=0, misses=1, maxsize=128, currsize=0)
CacheInfo(hits=0, misses=2, maxsize=128, currsize=1)
...
CacheInfo(hits=0, misses=4, maxsize=128, currsize=3)
CacheInfo(hits=0, misses=5, maxsize=128, currsize=4)
CacheInfo(hits=0, misses=6, maxsize=128, currsize=5)
CacheInfo(hits=0, misses=1, maxsize=128, currsize=0)
CacheInfo(hits=0, misses=2, maxsize=128, currsize=1)
CacheInfo(hits=0, misses=3, maxsize=128, currsize=2)
CacheInfo(hits=0, misses=4, maxsize=128, currsize=3)
200 loops, best of 5: 2.1 msec per loop

So even though only one FastPath is constructed for each root, the 'lookup' cache never has any hits. I've confirmed also that the mtime is unchanged from call to call. I just do not understand why the lookup is not being cached.

[jaraco]

Aha. I've figured it out. The cache_clear is getting called when os.mtime raises OSError.

[jaraco]

Looking at the alternate implementation in #274, I see the difference lies in how the lookup cache is cleared. In 274, the cache is per-FastPath, but in this PR, the cache on lookup, although it takes into account self in the key, when cleared gets cleared for all instances of FastPath.