Comments on: Java: Chronicle Bytes, Kicking the Tires https://speedment.com/java-chronicle-bytes-kicking-the-tires/ Build Fast Java Applications for the Fastest Business Performance Fri, 01 May 2020 05:21:37 +0000 hourly 1 https://wordpress.org/?v=5.1.1 By: Per Minborg https://speedment.com/java-chronicle-bytes-kicking-the-tires/#comment-43 Thu, 25 Jul 2019 11:00:03 +0000 #comment-43 Thank you for you comment. I have added a call to order(ByteOrder.nativeEndian()) and re-run the benchmark. Surprisingly, the difference was not so big even though there was a slight reduction of the difference between the two types:

Benchmark Mode Cnt Score Error Units
Benchmarking.equalsByteBuffer thrpt 3 4281578.767 ± 1677644.935 ops/s
Benchmarking.equalsBytes thrpt 3 16760740.637 ± 16154322.778 ops/s
Benchmarking.serializeByteBuffer thrpt 3 26954828.981 ± 1955935.164 ops/s
Benchmarking.serializeBytes thrpt 3 34255636.384 ± 4456939.630 ops/s

]]> By: Anonymous https://speedment.com/java-chronicle-bytes-kicking-the-tires/#comment-44 Wed, 24 Jul 2019 09:15:59 +0000 #comment-44 The benchmark looks a tad suspicious – note that ByteBuffer is BigEndian by default, whereas Bytes is native endian. This means that, on Intel, your benchmark will swap bytes with the ByteBuffer API. I suggest adding a call to order(ByteOrder.nativeEndian()) and re-run the benchmark.

]]>