A lot of people pointed out that they didn't really understand what was the point of this. Or what does it actually mean.

The main job of a lib of this nature is: send events down the pipe; eventually, or not, there will be an observer that will do something with them. You can then, of course, add all the transformations, UI binds, and other goodies.

Based on that, the tests went like this:

  1. See the overhead of the events for a single observer.
  2. See the overhead for multiple observers of the same event.
  3. See how much a couple of transformations contribute to the overhead.

Now comes the question, what does it actually mean? Nothing really. These tests were not meant to answer the important things.[1]

  • what's the memory footprint.
  • How well the library cleans it up, after it's done with the work.
  • Are there any memory leaks?

And of course:

  • how well maintained the lib is.
  • Does the community have any interest in it.
  • How many core contributors does the lib have.
  • How easy is to setup and use.

Bottom line: use your best judgement, when seeing these kind of tests.

  1. I might do a more thorough comparison later. ↩ī¸Ž