Performance overhead of subscriptions

[bdach]

An implementation of a feature in our project that uses realm leans pretty heavily into keypath-filtered change subscriptions. That implementation will instantiate one keypath-filtered subscription per instance of a model type called a "collection".

I am worried about the performance implications of this, and how far this will push the subscription system. Is there some concrete data about how many active subscriptions we can have concurrently active without performance breaking down? What would the worst usage pattern with respect to subscriptions be?

For an estimation of scale, currently in the project we'd have about ~20 ambient subscriptions active at any given time, and for power users this one-subscription-per-collection assumption could push the number of ambient subscriptions well into the hundreds.

[nirinchev]

I'm not super familiar with the Osu codebase, but if I understand the code correctly, this feature doesn't take advantage of keypath filtering at all. The way I read the intent, it can be roughly simplified to:

List<IDisposable> tokens = new();

foreach (var collection in realm.All<BeatmapCollection>())
{
  tokens.Add(collection.BeatmapMD5Hashes.SubscribeForNotifications(...));
}

Since BeatmapMD5Hashes is a List<string>, keypath filtering would be irrelevant there. I guess the only place where you actually want keypath filtering is for monitoring the realm.All<BeatmapCollection>() collection and then removing/adding subscriptions as users are creating/removing new collections. I don't see the code for where this is happening in this PR, but there you definitely want to use the .CollectionChanged event or wait until #3501 is released so that you can get notifications when the collection changes, but not when the items in the collection change.

If my understanding is correct, then the main question is whether having 80-800 idle-ish subscriptions (I'm assuming the BetmapMD5Hashes collections don't change super rapidly) will have noticeable perf impact. I've asked the DB team for guidance on this, but it'd be good to get a confirmation on your end that I'm not missing something.

[bdach]

I guess the only place where you actually want keypath filtering is for monitoring the realm.All<BeatmapCollection>() collection and then removing/adding subscriptions as users are creating/removing new collections

Fair point, that's right, and we do do this. The top-level subscription that manages the item-level subscriptions would be here. Underneath that's a QueryAsyncWithNotifications(), so I guess we would want #3501 first?

whether having 80-800 idle-ish subscriptions (I'm assuming the BetmapMD5Hashes collections don't change super rapidly) will have noticeable perf impact

That's correct. The collections shouldn't be seeing many writes, as they're mostly user-managed, so any IO there is... let's just say meat-interface-limited, other than maybe the operation of bulk deletion of all collections we offer (but I don't expect that to be slow). The count alone is mostly what worries me here, and in the review I was advocating for more conservative usage (either limiting to one subscription across all model instances, or only taking them out as the relevant view is active and then stopping watching them as long as the view is gone).

[nirinchev]

Cool - I spoke with the team and we don't have explicit performance tests for this, but the overhead of individual subscriptions should scale linearly with a small constant factor for collections which don't see changes. Beyond 100(s) of individual subscriptions, we expect a single subscription with keypath filtering to be more efficient though, so once #3501 is released, you could optimize the use case like:

realm.All<BeatmapCollection>().SubscribeForNotifications((sender, changes) =>
{
  foreach (var inserted in changes.InsertedIndices)
  {
    var beatmapsCount = sender[inserted].BeatmapMD5Hashes.Count;
    CreateNewDrawableCollectionListItem(inserted, beatmapsCount); // Pseudocode
  }

  foreach (var updated in changes.NewModifiedIndices)
  {
    var newCount = sender[updated].BeatmapMD5Hashes.Count;
    UpdateExistingDrawableCollectionListItem(updated, newCount); // Pseudocode
  }

  foreach (var deleted in changes.DeletedIndices)
  {
    DeleteNewDrwableCollectionListItem(deleted); // Pseudocode
  }
}, new[] { "BeatmapMD5Hashes" }); // Only invoke this if BeatmapMD5Hashes changes

Not sure how easy it would be to plug this into your infrastructure, but it should perform better than individual listeners for large number of subscriptions and slightly worse for small number of BeatmapCollections. That being said, 100s of subscriptions shouldn't have a major negative impact and you may very well be fine just going down the path outlined in the linked PR. It also depends on the frequency of database operations and whether you're performing writes on the main thread.

Finally, unsubscribing and resubscribing on demand would be the most conservative (and future-proof approach) and that would be my default preference as long as it doesn't introduce too much complexity in the codebase.

[bdach]

Thanks so much for the detailed response!