Performance comparison with Rx and Combine

[olejnjak]

Hi,

I came across this repository (https://github.com/quickbirdstudios/CombineRxSwiftPerformance) comparing performance of RxSwift and Combine, so I thought 🆒 I’ll try to add ReactiveSwift. So I did, but when I did I was very surprised, as ReactiveSwift is much much slower than the other two (QuickBirdEng/CombineRxSwiftPerformance#3). Does anyone know if it is really that slow or the tests are just not doing what they should?

The results end the same while integrating using Carthage so some build configuration issues do not make a difference.

Sorry for duplicate to Slack post, but an issue would more maintainable.

Thanks in advance

[andersio]

The result is quite surprising to me as well, since some preliminary benchmarking I did for performance optimisation over the last years was telling otherwise. I will have a look.

[andersio]

Just to share some preliminary thoughts:

It seems the main performance deficit is contributed by Signal and by extension all Signal operators being lifted to SignalProducer. I am investigating why Signal, especially composed ones, is performing particularly bad wrt RxSwift. One thing I am sure is that it is very likely about how abstractions in ReactiveSwift go well along with the compiler optimisations, or that Combine/RxSwift use patterns that are targeted by the optimiser.

It also appears that the SignalProducer optimisations we did in the past years are along the right direction, given that the items where RAS perform on par with RxSwift.

As an example, I reimplemented SignalProducer.switchToLatest at purely SignalProducer level (which still involves Signal but way less than lifting the Signal version). It performs 44% better in instantiation and 75% better in event propagation.

[RuiAAPeres]

Hello. 👋 Thanks for opening this issue. Due to inactivity, we will soft close the issue. If you feel that it should remain open, please let us know. 😄