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+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@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/9DB729A0-7C52-4A30-8CFC-CBEBEDE819E3%40ix.netcom.com.
