Skip to content

Conversation

@defunctzombie
Copy link
Contributor

@defunctzombie defunctzombie commented Dec 22, 2023

We make heavy use of Comlink for our WebWorker communication. On some recent profiling traces I noticed a hot-path on the "addEventListener" line.

Screenshot 2023-12-21 at 6 31 48 PM

While its hard to say exactly how the event listeners are stored, most implementations I've seen for such interfaces involve storing them in an array and removing the listener equally requires adjusting an array. The existing logic also creates two closures - one for the Promise (which is unavoidable from what I can tell), and another for the event listener. As it was suggested in #647 there is a potential for improvement by using a single "message" event listener and doing the dispatch manually by looking up the resolve functions in a Map.

This definitely reduces the runtime cost of the requestResponseMessage call itself - though there's still cost to new Promise and the closure. There's a shifted cost to the ID lookup on the map though in my profiling that did not show up as a hot path item.

Conceptually using a map for the lookup and one handler seems like it should perform better but if folks have some ideas on how to more robustly benchmark this PR that would be helpful.

@josephrocca you filed #647 so maybe you have some thoughts?

Fixes: #647


TODO:

  • figure out how/when to remove the listener
  • register the listener once for the "Endpoint" even when many proxies are created for the endpoint

@google-cla
Copy link

google-cla bot commented Dec 22, 2023

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@Tsury
Copy link

Tsury commented Dec 22, 2023

Hey @defunctzombie and @benjamind, please check #651. It's not complete either, but I think that it improves performance drastically, maybe we can use both PRs to create a better solution.

@defunctzombie
Copy link
Contributor Author

Closing in favor of #653

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

Successfully merging this pull request may close these issues.

Significant performance optimizations possible in requestResponseMessage

2 participants