Repository navigation
Cache discoverable items that do not change #141
Description
Activity
@dietzc @ctrueden @dscho I have a partial solution on https://github.com/scijava/scijava-common/tree/cache-annotations
Aside from cleanup and documentation, do you think it's worth waiting to merge until we have a cache service that can manage these cached objects? Otherwise I'm worried about their endless proliferation.
(also, the current caches are slightly wrong at the moment because of the recursion of the annotation scraping)
Hmm... I would have to spend time to wrap my head around those methods to understand the commits. Do you have any numbers about performance improvements? (If it improves how fast SCIFIO opens files, I will set aside time to review the commits, but if there are lower hanging fruits, I'd prefer to go for them first.)
Hey look, a chart
Results from running a 7KB .tif
Force pushed my latest changes, which I believe are now correct, and improve the Cache-Fixes times slightly.
OK I'm happy with this now that I have semi-consolidated the
getAnnotatedMethodsandgetAnnotatedFieldslogic in a way that allows for arbitrary annotation:object scrapings in a single recursion operation.@ctrueden if you get a chance can you sign off on this? Since it's a low-level change I want another pair of eyes on it.
Wrote a bunch of comments! (They would be visible here had you filed a PR like normal people do. 😛)
Continuing my trend of not acting like a normal person, I did not make a merge commit that closed this issue!
So instead, see these commits which resolved this issue.
During context injection, there are method and field annotation lookups, plus event handler registration, that is repeated when the results should be consistent for a given set of input parameters.
The repetition of these queries leads to significant overhead during high loads of context injection.
Thus we should be caching these results.