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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
