@mikelehen Is this the same form that you recommended for web & saw in Android?

Hrm... Actually, looking closer (sorry I haven't looked at all this code in 4+ years):

1. This does look the same as Android.
2. I think both Android and iOS are actually wrong / non-optimal, though not as bad as web was. We're still calculating existing at the root of the update instead of for the individual updated paths (but fortunately only once instead of repeatedly like web was).

I think maybe we could change resolveDeferredValueCompoundWrite to take the SyncTree and writePath (instead of existing) so that it can calculate exiting data only at the paths being updated. TBH this might end up being somewhat equivalent to your just-in-time SyncTree thing, though I'm not sure and I think it's better to avoid the additional indirection of that approach.

I think as-is this code is doing extra work and may behave incorrectly depending on what's in cache, since I think calcCompleteEventCache() will return an empty node if we don't have data cached for the location in question. So if you have data cached at /foo/bar but not /foo and you do fooRef.update({'bar': ServerValue.increment(1)}) then we'll end up calling calcEventCache() at /foo, getting an empty node, so even though later we will correctly do existing.child('bar'), it will still be empty and we'll apply the increment to an empty node instead of the value we have cached for /foo/bar.

Sorry I missed this when I looked at Android. This code was tricky to begin with and I haven't looked at it in too long.