On 2024-02-25 Brett Okken wrote: > I created https://github.com/tukaani-project/xz-java/pull/13 with the > bare bones changes to utilize a utility for array comparisons and an > Unsafe implementation. > When/if that is reviewed and approved, we can move on through the > other implementation options.
Thanks! Ideally there would be one commit to add the minimal portable version, then separate commits for each optimized variant. So far I have given it only a quick try. array_comp_incremental seems faster than xz-java.git master. Compression time was reduced by about 10 %. :-) This is with OpenJDK 21.0.2, only a quick test, and my computer is old so I don't doubt your higher numbers. With array_comparison_performance the improvement seems to be less, maybe 5 %. I didn't test much yet but it still seems clear that array_comp_incremental is faster on my computer. However, your code produces different output compared to xz-java.git master so the speed comparison isn't entirely fair. I assume there was no intent to affect the encoder output with these changes so I wonder what is going on. Both of your branches produce the same output so it's something common between them that makes the difference. I plan to get back to this next week. > > One thing I wonder is if JNI could help. > > It would most likely make things faster, but also more complicated. I > like the java version for the simplicity. I am not necessarily looking > to compete with native performance, but would like to get improvements > where they are reasonably available. Here there is some complexity in > supporting multiple implementations for different versions and/or > architectures, but that complexity does not intrude into the core of > the xz code. I think your thoughts are similar to mine here. Java version is clearly slower but it's nicer code to read too. A separate class for buffer comparisons indeed doesn't hurt the readability of the core code. On the other hand, if Java version happened to be used a lot then JNI could save both time (up to 50 %) and even electricity. java.util.zip uses native zlib for the performance-critical code. In the long run both faster Java code and JNI might be worth doing. There's more than enough pure Java stuff to do for now so any JNI thoughts have to wait. -- Lasse Collin
