-
Notifications
You must be signed in to change notification settings - Fork 140
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
Koloboke Obj Maps slowed down with Java 8 VMs #42
Comments
Is there any update on this issue? I am also wondering if there is supposed to be a performance advantage of using JDK8 vs JDK6-7 flavor of the library on Java8 runtime. Are there any benchmarks comparing these two cases? Is there anything about JDK8 flavor that is supposed to make it faster / more compact? |
I did some benchmarking after that SO discussion and found that it is not that bad for Koloboke actually.. sometimes it is still considerably faster than HashMap. Also, as the result of thinking about these issues the https://github.com/OpenHFT/SmoothieMap project emerged. Koloboke tend to perform worse when keys are actually compared by The outcome is: make the benchmark closest to your real case (or better just substitute hash map impls in your real case) and compare performance metrics. HashMap might appear to be the fastest on average, but in majority of cases I expect either Koloboke or SmoothieMap to outperform HashMap. They are three different algorithms with different performance consequences.
The idea was indeed to improve in Jdk8 but actually they don't differ yet. Just use the version according to you runtime Java version. |
The striked statement above is incorrect. To be more specific, when key is queried, average number of times it is compared by
So SmoothieMap compare keys more often than HashMap, but still very rarely |
See http://stackoverflow.com/a/31994785/648955
The text was updated successfully, but these errors were encountered: