-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
poc: replace cachy with cache module #5868
poc: replace cachy with cache module #5868
Conversation
Have not gone through the cache logic itself, but left some high level comments regarding the change. |
149dcf8
to
8f9c039
Compare
@chadac any progress on this? |
@Secrus Apologies, got pulled into some busy separate stuff that has occupied my time. I'll commit to get some of those profiling stats up for next week so to help reach a decision on one of those threads above (for |
56bb897
to
360f8a2
Compare
Posted an update which cuts down a lot of the junk. I did do a test on the proposed |
894d70c
to
05130ea
Compare
I did end up running a more complete performance comparison for the package & match cache. The results mostly agreed with what was shown earlier; when comparing 50 identical runs between the two, the improvement in performance was about 0.5%, which was well within the margin of error (difference in average: 0.3s, with standard deviation of +/- 3.2s). The student t test reports a p-value of around 0.6, indicating that there was very little certainty that this adds any improvement at all. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks really good to me -- could you address the last review comments and then squash history into something mergable?
e.g. two commits: introduce FileCache and tests, then cut over to the new FileCache
Sounds good, lemme refactor the commits. |
beae7fe
to
6f74773
Compare
6f74773
to
0136c33
Compare
0136c33
to
a7e5f9a
Compare
At #5868, I [suggested](#5868 (comment)) that some of the caching that was being reworked could be removed altogether, because cachecontrol was already taking care of it just fine. But now I find myself using an Azure artifacts repository, and it is returning headers that insist that the client does not do any caching: ``` cache-control: no-cache pragma: no-cache x-cache: CONFIG_NOCACHE ``` (pypi, by contrast, sets max-age to 10 minutes here). So I was wrong! And now I am seeing a big performance hit in some projects where the solve involves overrides and backtracking: and therefore hitting the legacy simple API repeatedly. However, we don't need all the mechanism of cachy and its like for this, a well-placed `@lru_cache()` seems more than sufficient. This makes me wonder whether it wouldn't be better to do similar for pypi anyway, and rip out cachecontrol altogether. But let's keep it simple for now: this is an easy fix to a performance regression.
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Related to the discussion in #5720.
This is a test to see what would be needed to pull out of cachy to get it into Poetry entirely. The result is a new utils module,
poetry.utils.cache
, that is about 250 LOC. I also went ahead and made a couple of small improvements:FileCache
,DictCache
Pull Request Check List