Javonet performance 10x slower compared to native

Question

In another post, I talk about the need for support of primitive array in javonet. Could this explain why pulling ~2GB worth of double array is about 10x slower than comparable code in .net? I've attached a screenshot of JProfiler in case it helps. (Also, though not shown, JProfiler also showed about 1GB of Double objects, which I think should not exist if we just had primitives; but, is this the reason for the slowness or is it because of the ~40,000 calls to a .net method, and all the "stuff" in between with Javonet etc end up taking a few hundred miliseconds or so?)

UPDATE 5/3/2018:

If you read the comments to the first response, you'll eventually see a build (hf16) which resolves the slowness problem. Javonet appears quite fast....I imagine that this build will eventually make it into the core product.

Answer 1

Jonathan, deeply analyzing your case the answer to your performance issues comes from variety of factors. Let me explain them one by one:

1. Boxing/Unboxing - indeed this had an impact on your results, as answered in this thread How to avoid autoboxing of primitives in arrays in javonet there is beta release which includes ability to force Javonet to use primitive arrays as result. So this issue can be resolved easily.
2. Unnecessary Strings Passed as mentioned here Performance of Javonet current release of Javonet for Java developers is still suffering from an issue that even for optimized subsequent method calls the method name was passed to .NET side and converted to .NET string. Moreover for each result the type name was returned and converted to Java string. This has been resolved in Javonet for .NET developers already. We addressed this issue for you in temporary build merging those optimizations into Javonet for Java developers. (link below).
3. Data Type Conversion analyzing your results we found out an issue in "double" processing that might have affected your performance. This is also covered in temporary build linked below.
4. Type of Operation for Javonet the most costly operation is the on the fly conversion of value-types. Depending on time its either superfast (i.e. boolean) or quite costly (i.e. UInt64). So your case is special as you do few cross-boundry calls but you do a lot of value-type conversion (2GB of array). Completely different results you should observe if you compare calling many times (i.e. 250k) method generating prime number for growing "x" argument. (if you compare that to calling same method via web services i will be 1000x faster)
5. Way of Comparing Results lastly but very important is that Javonet performance varies depending on the operation you do and way you compare the results. It's clear that if you invoke a method which does nothing purely in .NET it will be optimized by compiler and execute in almost "no time". When you call it through Javonet it will take some "tiny" time (i.e. 0.0000009s) to pass the call to .NET. In result when you divide "tiny" by "no time" it is like dividing 10 by 0 so you could assume its infinitly slower (does it mean Javonet is slow? - not exactly). However if you call a method which does some processing or retrieves data from DB etc.. then Javonet overhead will be almost unoticable.

Unstable beta release with fix for faulty string exchange and double data type conversion: ...link removed due to newer release included in update below...

Please use this only for measuring purposes. We would be happy to know your results. Soon those changes will be merged in stable state to official build and we will inform you afterwards.

Summarizing: There are different reasons for the performance results you obtain. Some of them are being addressed by beta patch mentioned above, some are related to the way you measure and operation you do. Javonet in many cases is the fastest native integration technology between .NET and Java, as recognized in tests of many our customers and trusted in solutions like high frequency trading, real-time data processing, controlling manufacturing and medical devices and other... Of course there are still situations and cases where performance varies. Achieving highest results is one of our key priorities, following one of our principles "be faster with each release". We always accept performance challenges of our customers implementing on-demand improvements if needed. We do accept yours and will strive to optimize for big primitive arrays retrieval as well.

Please test the patch above which should expose significant improvement but still will suffer from environmental reasons points: 4 and 5.

Update 2018-04-30: We have started the implementation of modernized optimization module to address scenarios like yours preserving highest possible performance almost equal to native. Under link below you will find alpha release which works in "usePrimitiveArraysMode" for non-generic methods returning "double[]" without ref/out arguments. I.e. double[] CreateArray() or double[] CreateArray(int size) etc...

http://download.javonet.com/1.5/javonet-1.5hf15-primitivearrays-opti-jtdn.jar