-
Notifications
You must be signed in to change notification settings - Fork 391
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
Significant performance optimizations possible in requestResponseMessage
#647
Comments
+1 The createProxy method is also applicable |
+1 |
I'm not related to this project, but most likely I would have a single listener per ep, and a Map of pending calls, associating the id to the resolver. That would ensure there is only a single event listener executed per received message. |
I'm using Comlink on a Deno server that is handling a lot of traffic - I'm just passing a string to the worker, and then the worker is sending back ArrayBuffers (I'm using
Comlink.transfer
for sending those, of course), and it turns out that Comlink has become a bottleneck on the main thread - specifically this code:I'd have thought that V8 would have some magic optimizations to make the function creation here not as expensive as it seems to be. It looks like it's creating a "fresh" function each time, and then isn't able to optimize it since it only gets called once, and so simple stuff like
!ev.data || !ev.data.id
runs slow because it's basically running in "interpreted" mode. That's my guess here, anyway.I'm wondering if you'd welcome a pull request which optimizes this, and if so, do you have any preferred approach? My thinking here is that you'd just have a single function (rather than creating a new one for every request), and it uses a
Map
which maps anid
to itsresolver
.The text was updated successfully, but these errors were encountered: