Ask and ye shall receive… So, first with running using the GraalVM JDK 11 Community Edition:
insert time 10000000 records = 19305ms, usec per op 1.9305 close time 12313ms scan time 10695ms, usec per op 1.0695 scan time 50% 461ms, usec per op 0.922 random access time 12.014us per get close with merge 1 time 0ms scan time 9685ms, usec per op 0.9685 scan time 50% 456ms, usec per op 0.912 random access time 11.986us per get then I created the statically compiled binary: insert time 10000000 records = 33182ms, usec per op 3.3182 close time 23602ms scan time 15104ms, usec per op 1.5104 scan time 50% 670ms, usec per op 1.34 random access time 23.85us per get close with merge 1 time 0ms scan time 15093ms, usec per op 1.5093 scan time 50% 705ms, usec per op 1.41 random access time 24.271us per get oops, not so good. So then I downloaded the enterprise versions and created a profile guided optimized static binary: insert time 10000000 records = 21705ms, usec per op 2.1705 close time 13792ms scan time 10415ms, usec per op 1.0415 scan time 50% 479ms, usec per op 0.958 random access time 13.582us per get close with merge 1 time 0ms scan time 10391ms, usec per op 1.0391 scan time 50% 479ms, usec per op 0.958 random access time 13.557us per get The binary size of the last is 8.5 MB. For comparison, the Go binary is 3MB. > On Dec 22, 2020, at 10:55 AM, flying_dutchman <[email protected]> wrote: > > 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 [email protected] > <http://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, [email protected] <http://suarezhouse.net/> >> <[email protected] >> <applewebdata://6FD0430C-7AD3-4721-B418-DD571DAC492D>> 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 [email protected] >> <http://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 [email protected] >> <applewebdata://6FD0430C-7AD3-4721-B418-DD571DAC492D>. > >> 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/37374167-c575-407f-971b-78f2b1c3131bn%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/37374167-c575-407f-971b-78f2b1c3131bn%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/C023150B-B24E-4D12-9C55-64B49DC4BE33%40ix.netcom.com.
