search

konsoletyper / teavm

Compiles Java bytecode to JavaScript, WebAssembly and C
https://teavm.org
Apache License 2.0
2.62k stars 262 forks source link

Add JSO-specific optimizations #809

Open konsoletyper opened 11 months ago

konsoletyper commented 11 months ago

Recent versions of JSO can produce wrapping/unwrapping functions. JSO does its best to reduce numbers of these extra functions, however, general optimizations may add new possibilities to detect and remove some unnecessary conversions. However, knowledge of JSO is not only part of particular backend, but also the part of a separate plugin. So, first a mechanism should be introduced, so that plugins could contribute their own optimizations into optimization chain.

McMurat commented 10 months ago

I am passing a lot of objects which extend JSObject between JS and Java. Do the recent JSO changes introduce additional wrapping calls which impact the performance here in a negative way? Or is there no difference as long as I am not interchanging non JSObject Java objects?

konsoletyper commented 10 months ago

@McMurat the only way is to tell is compile with new version and profile the code.

McMurat commented 10 months ago

@konsoletyper That's true, but I was asking to better understand the new implementation here. You write that there may be unnecessary conversions. My understanding is, that JSObjects are always returned by reference and every function made accessible from JavaScript which returns a generic java.lang.Object type (or something else which is not guaranteed to implement JSObject) will undergo potential wrapping, right? Will your recent changes to java.lang.String (use native JS strings internally) also avoid wrapping/conversions in cases where an API function strictly returns java.lang.String type?

konsoletyper commented 10 months ago

Sorry, I can't answer you question. If you are experiencing performance degradation after migration to 0.9.0, please, file an issue and I'll see if optimizer can be improved. But still, there's no answer to general question, nor can be anything 100% guaranteed by the optimizer.

Will your recent changes to java.lang.String (use native JS strings internally) also avoid wrapping/conversions in cases where an API function strictly returns java.lang.String type?

No, there still need in conversion. However, prior to 0.10.0-dev-1 any conversion would copy entire string. Since my recent changes only wrapper is created, but no strings copied.