-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
@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. |
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. |
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?) |
Yes, that event handling through Observable operators. |
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.
The text was updated successfully, but these errors were encountered: