I think it'd be a good idea if you can compile your Java port using GraalVM and benchmark the generated executable.
On Monday, December 14, 2020 at 2:58:15 AM UTC+5:30 ren...@ix.netcom.com wrote: > I did not, and honestly it is probably not a great comparison. > > Java requires the JVM - which is separate - so executables sizes are hard > to compare. The Java ‘executable code’ is tiny. > > As for runtime memory usage, it is fairly trivial since the data is stored > on disk with an in-memory ’skip index’. The skip index is nearly identical > between the two - Java probably having a bit more pointer overhead - but > the size of the in-memory index is configurable - so trading memory for > speed is up to the user. > > There is no way to cap the heap size in Go to offer an apples-2-apples > comparison. > > > > > On Dec 13, 2020, at 3:08 PM, da...@suarezhouse.net <da...@suarezhouse.net> > wrote: > > Super interesting. Did you happen to catch the runtime memory avg, > median, max and current "executable" file size difference? > > On Saturday, December 12, 2020 at 1:04:42 PM UTC-6 ren...@ix.netcom.com > wrote: > >> Hi all, >> >> I thought this might be of interest to some. I released a Java version of >> keydb <https://github.com/robaho/keydb> at jkeydb >> <https://github.com/robaho/jkeydb>. I primarily did the exercise to keep >> my Java skills fresh and do an updated performance comparison between Go >> and Java. >> >> Tests performed using OSX Big Sur. >> >> Using Go 1.15.5: >> >> insert time 10000000 records = 24670 ms, usec per op 2.4670965 >> close time 16945 ms >> scan time 10631 ms, usec per op 1.063149 >> scan time 50% 470 ms, usec per op 0.941686 >> random access time 9.658001 us per get >> close with merge 1 time 0.681 ms >> scan time 11253 ms, usec per op 1.1253718 >> scan time 50% 471 ms, usec per op 0.942876 >> random access time 9.702651 us per get >> >> Using Java 1.15: >> >> insert time 10000000 records = 24102ms, usec per op 2.4102 >> close time 13564ms >> scan time 10259ms, usec per op 1.0259 >> scan time 50% 474ms, usec per op 0.948 >> random access time 13.209us per get >> close with merge 1 time 0ms >> scan time 10142ms, usec per op 1.0142 >> scan time 50% 501ms, usec per op 1.002 >> random access time 13.28us per get >> >> Performance is very similar, except that Go is significantly faster in >> the random access tests. I attribute this to the JNI overhead in making >> lots of small IO requests. In a previous life I wrote some custom JNI code >> for ultrafast IO and I might resurrect that to see if it makes a difference. >> >> You can vary the ‘keyIndexInterval’ to trade memory for speed which >> significantly helps the Java version by reducing the IO. >> >> There are significantly fewer source (non test) code files in the Go >> version, 10 vs. 26 which highlights the simplicity of Go. >> >> Anyway, feel free to ask any questions if you wish. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/9079e608-2c6c-4547-8c27-ebbb48a2fe61n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/9079e608-2c6c-4547-8c27-ebbb48a2fe61n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/37374167-c575-407f-971b-78f2b1c3131bn%40googlegroups.com.
