search

WICG / observable

Observable API proposal
https://wicg.github.io/observable/
Other
575 stars 14 forks source link

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

Open smaug---- opened 1 year ago

smaug---- commented 1 year ago

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 commented 8 months ago

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---- commented 8 months ago

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 commented 8 months ago

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---- commented 8 months ago

Yes, that event handling through Observable operators.