Implement Op Lookup Caching#15
Merged
Merged
Conversation
This lines up better with expectation. It is otherwise impossible for a user to create two equal (equivalent? See scijava/scijava#36) OpRefs, even if they pass the exact same Objects to the matcher
This ensures that the hashCode is generated using each element of the types and args arrays and not using the array objects themselves. This ensures that two OpRefs that are considered "equal" (using ref1.equals(ref2)) will have the same hash code
This test ensures that OpDependencies are also added to the cache. This commit also extracts some of the logic to helper methods to reduce code duplication
Member
|
@gselzer Thanks! |
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
2 participants
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.
This PR implements a basic caching mechanism for storing the
Objects returned byOplookups. The underlying data structure is aMap<OpRef, Object>, where theObjectis theOpreturned by the matcher whenfindOpInstancewas called with the correspondingOpRef.TODO:
OpRefs. If not we would have to decide on a caching strategy and cache size: I think LRU makes sense, but we would have to implement a signal that tells the matcher whether or not to cache (and at that point, we might as well just implement Allow user to pass hints when calling Ops scijava#43). OtherwiseOpDependencyOpRefs will take over the cache.OpRef.equals(),OpRef.hashCode()are correct. This probably depends on decisions made within Document equality/equivalence semantics scijava#36I did spend a little time thinking about scijava/scijava#5, but I do not think that it belongs with this work. The matcher knows nothing about the
Objects themselves during matching, so this is not the place to insert that kind of behavior.Closes scijava/scijava#33