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

Investigate the performance of going through native <-> JS boundary in the API #68

Open
smaug---- opened this issue Sep 15, 2023 · 4 comments

Comments

@smaug----
Copy link

Filing this just as a reminder of discussions which happened during TPAC.

Event handling is a very hot code path.
When using the proposed API, there might be quite a few calls through native <-> JS and that might slow down processing, since it would be harder for JITs to optimize the relevant code and crossing the language boundary adds always overhead.

@domfarolino
Copy link
Collaborator

When using the proposed API, there might be quite a few calls through native <-> JS and that might slow down processing, since it would be harder for JITs to optimize the relevant code and crossing the language boundary adds always overhead.

@smaug---- Do you think there would be generally more of these native <-> JS flows/conversions, compared to usual event handling? Standard event handlers are a native platform concept, so I don't see how Observables makes things considerably different. This API just seems like a more ergonomic event handler.

@smaug----
Copy link
Author

oh yeah, the API certainly has higher native<->JS overhead. With events you often just check the type and then do the rest in JS. Calling preventDefault() or .stopPropagation() might happen, sure, but those might happen with the new API too.
The proposed API encourages going through the native side quite a lot.

@domfarolino
Copy link
Collaborator

With events you often just check the type and then do the rest in JS.

But the only reason you get to check the type and "do the rest in JS" is because you've already gone through the native DOM event handling/dispatching code, right? So the cost of going through the native boundary is already there before you even do any JS.

I guess you're saying that with Observables, the JS event handler would very often be forced to always go back through native, since the event would likely be plumbed through a chain of native Observable operators? Is that the cost you envision? (Whereas with traditional event handling, there is no pipeline of consecutive native event handlers that an event goes through after being handled by a single JS event handler?)

@smaug----
Copy link
Author

Yes, that event handling through Observable operators.

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

No branches or pull requests

2 participants