primus / eventemitter3

EventEmitter3 - Because there's also a number 2. And we're faster.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unsubscribe/subscribe performance

isRostCompany opened this issue · comments

Hello
Got more of a question, rather than an issue report, but I feel that it is unsuitable for StackOverflow or other places as it is really eventemitter3 specific. And also it would be perfect to hear some thoughts from people who actively develop this library.

Basically my issue is that for some use cases I might be triggering from 100 to 1000 unsubscribe/subscribe cycles per second.
Is that an issue for the library?

I could of course measure this, but my question is kinda more from a design and core ideas perspective.
If it sounds like smth that won't work well (as it was never designed to handle such workloads) then I will look into optimizing my approach.

Thank you in advance.

You should measure, but 100-1000 subs/second should not be a problem. If N is very high, there may be better approaches - the collection of callables is an Array (see addListener), not some kind of Set/Map, so removeListener() will be linear in the number of listeners per event instead of O(1).

Yep, exactly what bothered me - callbacks stored in array.
For my purposes I decided to store ref enclosing frequently changing dependency of a listener and only subscribe once.
But anyways, thanks for your answer :)