franz1981 edited a comment on issue #2844: ARTEMIS-1811 NIO Seq File should use RandomAccessFile with heap buffers URL: https://github.com/apache/activemq-artemis/pull/2844#issuecomment-533906809 I'm going to "tune" differently the optimization while reading/writing RandonAccessFile in chunks of 8192, because on https://github.com/netty/netty/pull/9591#issuecomment-533904873 I've measured that the allocator isn't a bottleneck when chunk size > 8192 and assuming single threaded usage (malloc -> free on the same thread). This has been shown using `async-profiler` on a benchmark code here: https://github.com/netty/netty/pull/9591#issuecomment-534000527 ATM AMQP and OpenWire could cause big buffers allocation on native space (on JNI), so I would reduce the impact of this by tuning chunk size just to reduce the foot print overhead of it. The overhead of file reading using `RandomAccessFile` and `byte[]` vs `FileChannel` and direct `ByteBuffer` is variable, but using the benchmark I've used on Netty [here](https://github.com/netty/netty/pull/9591#issuecomment-534002621) has given this result: ``` Benchmark (chunkSize) (fileName) (fileSize) (ioSize) Mode Cnt Score Error Units ChunkedFileBenchmark.readFullyFile 32768 /tmp/raf.tmp 10485760 32768 avgt 4 2153.527 ± 715.641 us/op ChunkedFileBenchmark.readFullyFileWithNio 32768 /tmp/raf.tmp 10485760 32768 avgt 4 1775.999 ± 831.715 us/op ``` That means about a 25% perf difference while using super-fast disks and I assume to be the same on write side.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
