Rx.NET/DynamicData vs R3/ObservableCollections

[legezam]

I am about to start a new project and became a bit puzzled by the current offerings for reactive programming in dotnet.

If I am seeing things clearly, you either choose Rx.NET and then the highly suggested collection library is DynamicData. The other path is to go with Cysharp/R3 and then you use Cysharp/ObservableCollections.

Sorry, this question could be asked in any of the 4 repositories but still I think this is the right place to come.

So basically, how do Cysharp and DynamicData compare in terms of performance? Does anybody have any knowledge about it? The whole R3 is said to be overcoming the perf bottlenecks and an inherent api design failure of Rx.NET and therefore ObservableCollections is intuitively expected to outperform DynamicData but is that real thing?

Am I also seeing clearly the two paths of the available options or there are further cross-pahts between these libraries?

Thanks!

[JakenVeina]

So basically, how do Cysharp and DynamicData compare in terms of performance?

As far as I'm aware, the core concept of R3 compared to RX (the API design failure, as the project considers it) is that errors are not considered a stream termination event. So, handling an error does not require rebuilding and re-subscribing the entire stream that it came from. I could see that providing performance improvements in scenarios where error messages are a hot path.

I've never really appreciated the idea of error messages being non-terminating. It's the logical equivalent of saying, in imperative programming, that exceptions should be caught and swallowed, by default. Like, imagine a NullReferenceException where the method call that triggered it just gets skipped, and then the program continues running from the next line, as if nothing happened. Maybe that's okay, depending on what the method was, but for that to be default behavior, everywhere? However, I'm not a game or game engine developer, and supposedly, that's a large target audience for R3, so maybe that kind of behavior makes more sense, in that context.

Does anybody have any knowledge about it?

Me personally, I don't have much direct knowledge. I've never run any benchmarks on R3 code, anyway. If you're interested, your best bet is probably to setup some reactive queries that make sense to you, or that represent your common use-cases, and benchmark them for both RX and R3 for yourself.

The whole R3 is said to be overcoming the perf bottlenecks and an inherent api design failure of Rx.NET and therefore ObservableCollections is intuitively expected to outperform DynamicData but is that real thing?

I was unaware that Cysharp/ObservableCollections existed, until now. At a glance, the set of collections they've implemented look solid, and do look like a rough-equivalent to what DynamicData has, particularly in the NotifyCollectionChangedEventArgs type, which is roughly equivalent to DynamicData's Change and ChangeSet types.

What I don't see is any equivalent to DynamicData's querying library, which is kiiiiiinda the entire point. People don't use DynamicData because they don't like Microsoft's built-in ObservableCollection<>, they use it cause they want to be able to write RX-style queries, but for collections instead of just single values. E.G.

using var subscription = modelLayerItems
    .Connect()
    .Filter(...)
    .Sort(...)
    .Transform(...)
    .Bind(out var viewLayerItems)
    .Subscribe();

So, as far as comparing performance, I don't see anything I can compare against.

I will mention, though, you should keep in mind that DynamicData, arguably, isn't ABOUT performance. Like I said above, the thing folks use DynamicData for is the fluent queries, which involves you breaking up your business logic into pieces, so they can be applied, piecemeal, to collection changes, on a per-item (or per-operation) basis.

What this means is that you're actually opting in to doing MORE work than you need (tracking per-item changes to your collections, at every step of your business logic). You're effectively choosing to sacrifice performance, in favor of code maintainability. That doesn't mean we haven't put a lot of effort into performance optimization, within DynamicData, but there's things about the fundamental concept (like allocating lists of per-item changes, each time you make a change at the source, and then again for each operator that the changes propagate through) that simply can't be optimized away.

If performance is a truly critical concern in some scenario, DynamicData's approach of itemized change tracking is probably just not compatible with that scenario. Realistically, this probably just means you identify hot paths where performance is a problem, and optimize DynamicData out of those, in favor of more traditional imperative approaches.