I'm not following this fix - it seems to just make 8 new directories every time a basefile is asked for. I don't think that will help performance, but maybe I'm not understanding something. How are you testing this?

This is one of the proposed solutions from the issue; it doesn't fix the problem of the cache's size being unbounded, but it solves the other problem of having too many files in the same single directory, which the issue mentions can be a bottleneck. make_dvi and the other functions use the path returned by get_basefile to cache/retrieve the file, so instead of all the files being stored in ~/.cache/matplotlib/tex.cache/ (or wherever the cache is specified in the config), it will store them as ~/.cache/matplotlib/tex.cache/xx/xx/xx/xx/, where the xs are the first 8 letters of the file hash.

As for unit tests, I wasn't sure how to go about implementing them because the cache is never cleared, so the TexManager module could just be returning cached files from a previous run, instead of creating them (I assume we want to test both creation and retrieval). Would it be alright to use something like shutil.rmtree in the tests on the cache directory to force the creation of the files?

OK - 4 deep is potentially 65k directories, most likely with only one file in it. Do we really want that overhead? Even just two-deep would probably be fine? Thats around 8 million files.

I see. I only did four levels based on the suggestion in the issue. To make sure I understand correctly, the 8 million number comes from 16^2 * 32000 (since 32k is where the bottlenecks begin according to the issue discussion)? I will also amend my commit to change to two-levels.

I wrote a test case that checks the path of the returned file from make_dvi contains the correct levels. I'm not sure of a good way to "clear" the cache in the test case without messing with multithreading and locks, so I have left it alone for now.

I'm not an expert on these caches - hopefully @tacaswell or @anntzer will clarify as I think they are both familiar.

I agree that clearing the cache during a process seems fraught. It might be desirable to touch files as they are used, and then clear old files at the beginning of the process before any race conditions can set up. Not sure if there is a huge performance penalty to touching the cache files, but seems easier than an sql data base to me.

We should only (and it looks like that this is the implementation) make folders what there is actually a file in them.

The (main) thing that filesystems have major performance issues with is many files or folders in the same rather than the absolute number of files / folders. This is having 1M files in a single folder is way harder on the file system than 3 layers of 100.

As a reference, git does this in .git/objects to one layer of 2 characters (but the many of the objects are packfiles and I think it makes sure that the total number never gets too big).

I guess I was concerned about 16kb of directory metadata for each file group that often only take up <1kb each.

I think trying to clean up the cache in the middle of a test run could be pretty nasty (I don't know if our process-level caches can handle that, in fact) and I'd say that we should not require tests here (the fact that the rest of the test suite -- specifically usetex tests -- works at all is good enough).

We should drop redundant characters?