On Thu, 20 Jul 2023 13:34:25 GMT, Alan Bateman <al...@openjdk.org> wrote:
> in those cases, will creating a ByteBuffer wrapper be overkill? Perhaps - but do we have any benchmark to back up that claim (or backing up the fact that Integer.toString would benefit from using ByteArray in the first place) ? It is likely that in code that is compiled and inlined, this will make no difference at all, as an object that is created, and then disposed of will be routinely scalarized (since there's no meaningful control flow). If in some cases we have reason to believe that we need more performance, we could always fall back and use Unsafe directly. I guess in general I'm a bit skeptical re. creating a class that wraps an array and exposes get/setXYZ that are implemented by Unsafe, adding some bound checks on top. That's 99.99% of what an heap buffer does. I've benchmarked BB quite a extensively given my work on Panama and I can assure that, if accessed using the right API (e.g. absolute addressing scheme, which takes an offset) and the right endianness (ByteOrder::NATIVE_ORDER), the performance of BB access is very very very close to Unsafe (esp. here, given that ByteArray also introduces some kind of bound check). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14636#discussion_r1269474889
