Repository navigation
Add a benchmarks page measured on 2026-10-12 with the suite that produces it, and label the 2019 pages as the old benchmarks - #26
Merged
Conversation
…uces it, and label the 2019 pages as the old benchmarks.
Documentation build overview
6 files changed ·
|
… method notes, and keep only the store versions in the environment list.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a current benchmarks page and keeps the 2019 pages as the old benchmarks. The existing pages were measured by upstream for DiskCache 4 in 2019; the new one was measured on 2026-10-12 with current versions of every store.
docs/benchmarks.rstand four charts indocs/_static/benchmarks/: the classic mix of the old page (gets, sets, deletes, throughput, footprint), four value sizes from 100 bytes to 1 MB, 95 % and 50 % hit ratios, 4 and 8 processes and 8 threads, and the Django cache backends. Stores: diskcache-communityCacheandFanoutCache(8), diskcache 5.6.3, memcached through pymemcache and pylibmc, Redis, lmdb, sqlitedict and shelve.report.py: DiskCache has the fastest read in the classic mix (2.6 µs, 6 times memcached and 16 times Redis), lmdb reads faster on a 100,000-key working set, writes are on par with memcached, the fork writes 9 to 14 % faster than 5.6.3,FanoutCache(8)is the fastest setup across 8 processes while 8 threads in one process should share a singleCache, and lmdb's writes take about 6 ms because it flushes on every write. The environment list names the server and store versions.tests/benchmarks/: the suite that produced the page.driver.pystarts memcached and Redis and runs each store in its own process, from one environment with diskcache-community and one with diskcache 5.6.3;report.pywrites the page and charts from the JSON results. The stores importdiskcache_communitywhen installed and upstreamdiskcacheotherwise, so the same code measures both.report.pynow takes the measurement date from the results and builds the comparison table. pytest ignores the directory.comparisons.rstanddevelopment.rstpoint to it, anddevelopment.rstdescribes both sets of scripts.Verified: the page and charts regenerate from the saved results of the 2026-10-12 run with no difference; a smoke run of the suite against diskcache-community, diskcache 5.6.3 and the Django backend works; 518 tests pass; blue, isort, flake8, doc8 and the Sphinx build with warnings as errors pass.