Github user andrewcraik commented on the issue:
https://github.com/apache/spark/pull/15713
I do agree we should save the extra object allocation, but again whether we
should flatten the array into the class or remove the class and use ArrayBuffer
directly is the question - do we want to preserve the semantic distinction of
the type intents or loose it for simplicity? I'm not sure what the right
trade-off is, but preserving the class would provide future ability to tune
that would be lost by removal of the type.
While reordering branches might help a bit, the size of the method in
bytecodes is inflated by having the primitive fields for 0 and 1 leading to
reduced icache locality, longer distance branches and more complexity for the
JIT compiler to handle. Part of the performance gain from removing the field is
just from making the code smaller and simpler for the Java JIT.
Perhaps if the feeling is that there is value in the semantic meaning of
the type due to the trade-offs it implies finding some way to not just delegate
might be the best way forward?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
