Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add JSO-specific optimizations #809

Open
konsoletyper opened this issue Oct 8, 2023 · 4 comments
Open

Add JSO-specific optimizations #809

konsoletyper opened this issue Oct 8, 2023 · 4 comments

Comments

@konsoletyper
Copy link
Owner

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
Copy link

McMurat commented Nov 9, 2023

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
Copy link
Owner Author

konsoletyper commented Nov 9, 2023

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

@McMurat
Copy link

McMurat commented Nov 11, 2023

@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
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants