-
Notifications
You must be signed in to change notification settings - Fork 194
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
[OPTIMIZATION] Objects from methods that return 3 or more possible runtime-types optimize very poorly #183
Comments
Mmmmhhh... I think there are a lot of those. Like, the various .of() methods which optimize for an empty set, a singleton, etc. |
There are two offenders that immediately come to mind
|
The The |
Yeah, I thought about that. We can have an immutable empty list exposed directly by ImmutableList. I'm writing that. |
Great! :) I'm still finding unused classes like PrimitiveSpliteratorWrapperWithComparator in ByteSpliterators. |
Oops, I missed those. Forgot to check the shorter types' warnings. I'll fix those |
List.of and Set.of are the most important. Iterators.asXIterator and its cousin Spliterators.asXSpliterator are still an issue. However, the performance loss only happens if three or more returns of different types actually happen in a program run, not by merely being possible in the bytecode. And I can't imagine that many programs will trigger all three paths. Still should be looked at but less important. |
Specifically, the problem is the method that takes an Object based iterator and wraps it as a Fastutil primitive iterator (same for spliterator) I should try to measure which of these harms performance the least:
|
I think we can consider this done, right? |
Not quite. There is still the case.
But that is a pretty niche usage and I don't think it is worth blocking 8.5.0 over. |
OK, I'll leave this open then. |
Something discovered when optimizing Guava is that Hotspot (OpenJDK's virtual machine) optimizes megamorphic variables/returns (those that could be 3 or more different runtime types) far worse then it does mono or dimorphic ones (1 or 2 different implementations). Sometimes by factors in the double digits. (google/guava#1268)
As such, we should avoid static utility methods that can return potentially 3 or more different implementations.
This may (or may not) be better in newer JVMs, but in Java 8, the one we are targeting, it is absolutely an issue.
The text was updated successfully, but these errors were encountered: