Add ReactiveSwift tests

[olejnjak]

Hi,

as I usually use ReactiveSwift I thought it would be great to add it to the comparison as well.

[grafele]

Wow, amazing! I will take a look and also update the statistics before I merge it. Will then also include the numbers file, so that everyone can update the graphics as well.

[grafele]

I've added one comment and ran the tests locally. The crazy thing is, that the tests for ReactiveSwift are much much slower. Do you know any reason for this?

[olejnjak]

Not sure, I was as surprised as you are. I've opened a discussion on ReactiveSwift Slack if it is really that slow or the tests don't do what thay should (but I honestly doubt that)

[grafele]

Hmm ok. I would be ready to merge it, but I would prefer waiting for a response to your question in the slack channel. Maybe you can also ask in an issue on github as well.

[olejnjak]

Well the only answer I got so far is link to Twitter thread you are part of 🤷‍♂️ I’ll file an issue

[andersio]

Judging by the benchmark, I see a logical pattern here:

1. The MapFilter test cases involve only SignalProducer and two single-stream transform operators, which have been heavily optimised to reduce overhead (e.g. eliminate unnecessary locks ) whenever possible.

2. The rest of the test cases all either use the RAS thread-safe, multicast Signal primitive, or use operators that are backed by it (basically all flattening operators).

With (2), I can see how it can snowball into a significant deficit. Nonetheless, it would still be an interesting performance case to look into.