According to the example in https://www.javonet.com/java-devs/guides/working-with-net-arrays-and-collections-from-java-with-javonet/, if the dll that Java is calling returns an array of ints, Javonet will only display an array of Integer classes (not primitives). Since the arrays are huge in my case (~2GB worth of arrays), is there any way for Javonet to NOT autobox, but instead return an array of primitives?
Asked
Active
Viewed 145 times
2
-
FYI: I ask because with 2GB worth of primitives in an array, I am assuming that boxing and then autoboxing would hurt performance significantly (based on my past experience with autoboxing) – Jonathan Sylvester Apr 24 '18 at 16:17
-
Jonathan indeed current Javonet for Int32 arrays will by default return the boxed Integer array. However we do agree with your suggestions that it should be possible to get pure int[]. Our development team is working on that and I hope we should be able to release some hot fix for that (it could take around 1-3 days). – Przemysław Ładyński Apr 24 '18 at 19:09
-
That'd be great! This is probably obvious, but in our case, it's an array of doubles and an array of floats (all primitives) that we're extracting. (I mentioned Integers previously just to keep it in line with the Javonet example, but I imagine that all primitives should (ideally) be supported.) – Jonathan Sylvester Apr 27 '18 at 01:05
-
Also, just so I'm clear, will Javonet internally just cast Float to float (which i can do myself) or will it somehow be smart enough to realize that if .net is using an array of primitives, that it can return the same array of primitives (would it even be the same memory space so that we avoid CPU & memory cycles in unnecessary copy?) – Jonathan Sylvester Apr 27 '18 at 01:07
-
We receive the value in a raw format from .NET side so we will just create from the raw Java primitive types not cast the boxed to unboxed. – Przemysław Ładyński Apr 27 '18 at 13:35
-
Great! I'm testing performance right now, and I wouldn't be surprised if the bottleneck I'm seeing is due to the conversion of primitive to Objects. So, how and when can one get this latest build that fixes this issue? – Jonathan Sylvester Apr 27 '18 at 17:29
1 Answers
0
We have implemented the mechanism to allow you choosing if Javonet should return boxed or unboxed arrays. It can be used for entire scope of your application or set temporarily for particular operations, however please keep in mind that its beta build and the option affects all threads so if used selectively should be used with caution.
Please use this build: http://download.javonet.com/1.5/javonet-1.5hf15-primitivearrays-opti-jtdn.jar
To activate primitive arrays mode call at any time:
Javonet.setUsePrimitiveArrays(true);
This mode affects all primitive types: int, long, short, byte, float, double, boolean, char... To cancel this mode just set "false".
Once confirmed that it improves your performance, we will include that in final build and update this answer respectively.
Przemysław Ładyński
- 1,046
- 1
- 8
- 9
-
This build worked and reduced the time by half at least. (With some other tricks that have nothing to do with Javonet, I got the time reduced by another 5x....). I'm still testing to see if memory consumption was reduced as well, but at least *preliminary* results are positive. – Jonathan Sylvester Apr 30 '18 at 15:25
-
We have updated today this link from hf11 to hf15, could you please let me know which version you use? Is it hf15? Please check here https://stackoverflow.com/questions/50069008/javonet-performance-10x-slower-compared-to-native-net-code-may-be-due-to-object the hf15 should increase performance extremely for methods returning double[] and accepting either no arguments or non ref/out arguments. Looking forward to your results. More methods and primitive will be supported in upcoming days. – Przemysław Ładyński Apr 30 '18 at 15:29
-
Yes, we used hf15 (which worked). We also used hf12 (which threw runtime errors, but I see that you removed that link (which is good)) – Jonathan Sylvester Apr 30 '18 at 15:32