-
Notifications
You must be signed in to change notification settings - Fork 9
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
Improve hash implementations for immutable objects. #402
Milestone
Comments
mvanaken
added a commit
that referenced
this issue
Nov 8, 2023
Yes, it is a mutable field for immutable objects, which is why it is private and I created a separate class for it. I have considered to calculate the hash within the constructor, but this dropped performance as well, because then the hashes are always calculated, even if you do not need it.
mvanaken
added a commit
that referenced
this issue
Nov 8, 2023
mvanaken
added a commit
that referenced
this issue
Nov 8, 2023
mvanaken
added a commit
that referenced
this issue
Nov 8, 2023
This tests functionality as well as performance.
mvanaken
added a commit
that referenced
this issue
Nov 8, 2023
mvanaken
added a commit
that referenced
this issue
Nov 8, 2023
Since I already suggested to add the equality method to the interface, I happily oblige Sonar here.
mvanaken
added a commit
that referenced
this issue
Nov 8, 2023
mvanaken
added a commit
that referenced
this issue
Nov 10, 2023
…est. This does not stop the test after 500ms, which I expected, but checks if the runtime does not exceed this number.
mvanaken
added a commit
that referenced
this issue
Nov 14, 2023
mvanaken
added a commit
that referenced
this issue
Nov 24, 2023
…java Minor typo. Co-authored-by: Carly-1 <75033199+Carly-1@users.noreply.github.com>
mvanaken
added a commit
that referenced
this issue
Nov 24, 2023
Caching is an implementation detail. What is important is that it is a fixed or immutable hash code, hence the rename.
mvanaken
added a commit
that referenced
this issue
Nov 24, 2023
…Object. Fiddled the test numbers to find a scenario where the non-hash-caching implementation would still finish within a measurable time. Added a graph showing the different run numbers (on my computer) for comparison. The TimeOut is set quite large in comparison to the hash-caching implementation (2 seconds vs 55 ms), but that is to cover possible GitHub hickups. Processed review comments of @rdvdijk.
mvanaken
added a commit
that referenced
this issue
Nov 24, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some hash implementations in Metal are expensive and we should improve that to boost performance of Metal.
The general contract (JavaDoc) of hashCode() states:
In addition, see e.g. University of California, Berkeley, a good hash function meets the following criteria:
Criteria 1 and 7 are equal, criteria 2 and 4 are equal, and criteria 5 is met by using the Object.hash() method as much as possible which helps to spread the hashcodes evenly.
So, to implement good hash codes, we should consider the following simplified criteria:
All of the hash function implementations within metal meet these criteria, except for the last. Not all hashCodes are quick to compute.
The
DataExpressionSource
calculates the hash of the whole parseState it is dependent on and this source is created when usingTie
s in your tokens.When Values from a Tie of a large parsegraph are placed within a hashmap, this may cause a significant performance drop.
There are multiple solutions possible:
There is not neccessarily a choice between these solutions. We can actually implement them both.
The text was updated successfully, but these errors were encountered: