-
Notifications
You must be signed in to change notification settings - Fork 0
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
Optimize FieldLocation #1
Optimize FieldLocation #1
Conversation
eca8471
to
159ad26
Compare
@@ -33,7 +36,7 @@ public final class FieldLocation implements Comparable<FieldLocation> { | |||
|
|||
private final String pathToUseInRules; | |||
private final List<String> decomposedPath; | |||
private final List<String> pathsHierarchyToUseInRules; | |||
private final Set<String> pathsHierarchyToUseInRules; |
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.
provide O(1)
contains
instead of O(N)
for List#contains
used by hierarchyMatches(String)
@@ -163,7 +166,10 @@ public boolean equals(Object obj) { | |||
|
|||
@Override | |||
public int hashCode() { | |||
return Objects.hash(pathToUseInRules, decomposedPath, pathsHierarchyToUseInRules); |
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.
minor improvement to avoid implicit Object[]
allocation from Objects.hash
List<String> parentPath = new ArrayList<>(decomposedPath); | ||
parentPath.remove(decomposedPath.size() - 1); | ||
return new FieldLocation(parentPath); |
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.
This was allocating a lot of ArrayList
and FieldLocation
. I had tried return new FieldLocation(decomposedPath.subList(0, decomposedPath.size() - 1));
but that still allocates O(N)
FieldLocation
as pathsHierarchyToUseInRules
traverses the node's path to root.
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.
we could simplify the hash code by only using pathToUseInRules
since the fields are more or less variations of that information
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.
good call, String#hashCode()
is memoized and much less expensive than also including List<String>#hashCode()
and Set<String>#hashCode()
which are each O(N)
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.
updated
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.
Going to adjust this to satisfy equals verifier error
-> Significant fields: equals relies on decomposedPath, but hashCode does not.
FieldLocation maintains set of paths to use in rules ordered from leaf to parent. The set provides O(1) hierarchyMatches operation.
159ad26
to
f9b759a
Compare
FieldLocation maintains set of paths to use in rules ordered from leaf to parent. The set provides O(1) hierarchyMatches operation.
This addresses the following trace from JFR running some test cases using assertj 3.25.2 using
usingRecursiveComparison().isEqualTo
Check List: