Re: JsInterop and Java collections?

Hi 

Performance also matters. We build the clint for 3 platforms: iOS, Android, GWT.

Storing data in nio.Buffers has HUGE performance impact on mobile platforms. 

I see no problem with java->C++ interop with byte[] and float[] for mobile platforms (RoboVM, Android) and desktop.

I can do the same in TemVM. All primitive arrays there are Native. 

So that I can write portable and fast code for heavy application like 3d editor.  

The problem is that GWT does not support that. 

I must have 2 implementations for type[] for .get .set typed-array.

Using..get .set abstraction is very slow on mobile. It is virtual call. An array access 20x-30x times faster.

This is not OK. It would be nice if the GWT compiler had such option (off by default). 

It should be possible to preserve all compatibility by adding a new command line switch to the compiler command-line. 

I`m ok to break JSNI contact. And we use SSO, the only one and default implementation.

On Friday, June 10, 2016 at 1:33:19 PM UTC+3, Thomas Broyer wrote:

On Friday, June 10, 2016 at 11:12:27 AM UTC+2, Kirill Prazdnikov wrote:

Hi Thomas

Lets forget about java.util, what about simple arrays ? 

It seems that we already have java [] array -> JS Array marshalling. 

And It would be very nice if we had these type of marshalling with zero performance penalty:

 java byte[] -> Int8ArrayNative

 java short[] -> Int16ArrayNative

 java float[] -> FloatArrayNative

Currently, there is no way of writing GWT compatible portable code that operates with  byte[] short[] int[] float[] without java array[] -> JS TypedArray performance issues

I think there was an experiment to actually implement byte[] et al. as JS typed arrays, but there were issues with it (browser compatibility to begin with, meaning that some browsers would have JS Arrays and some JS typed arrays, so interop with JS would be made harder and errorprone; not to mention that the compiler would then need to know which kind of output it needs to use depending on the permutation, something I don't know it can do today; backwards compatibility: some libraries rely on "conversion" from one type to another by passing through the JSNI boundary, so you can easily send a int[] to JSNI and have it return back the same object as a double[] –maybe–, using an Int32Array to implement int[] would break that; also casting to Object[] conflicts with the new-implemented treatment of java.lang.Double the same as 'double', so double[] and java.lang.Double[] are implemented the exact same way, so you could retrieve a JS Float64Array as a java.lang.Double[] and then it would likely break when cast to Object[])

In the end, JS type arrays are more like typed java.nio.Buffers (java.nio.DoubleBuffer, etc.) than arrays; so you'd better work with a similar abstraction than with Java arrays.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.