-
-
Notifications
You must be signed in to change notification settings - Fork 5
Description
Describe the feature
The Crdt version of the Test CanSyncRandomEntry takes significantly longer than the fwdata version.
Here's the profiling data of the crdt version of the test with no round-trip API, which seems to confirm our suspicion that complex forms and components operations are quite expensive due to preventing reference cycles.
Profiling data was collected in Visual Studio by putting break points at the beginning and end of the test and using Record CPU Profile in the Diagnostic Tools view.
(Sadly I could not find a way to export any of the profiling results, but I've included lots of screenshots)
TLDR;
Checking for reference cycles or duplicate complex-forms/components accounts for approximately 1/5th of the entry sync time.
Summary of the test:
- We create an entry with 5 of everything (senses, example-sentences, complex-forms, components etc.)
- We make a significantly altered version of that entry:
- 5 new things of everything
- heavy modifications and deletions of everything
So:
- 5 components and 5 complex-forms are added
- components are moved around and some are deleted
- 5 senses and 25 example sentences are added
- existing senses and example sentences are shuffled and some are deleted
Bird's eye view
For profiling We focus only on the EntrySync.SyncFull(before, after, Api) code, because everything else is test infrastructure. (e.g. PrepareToCreateEntry).
SyncComplexFormsAndComponents and SyncWithoutComplexFormsAndComponents are almost equally expensive.
One would think that the former is significantly cheaper, because it only syncs 2 fields, but it's actually more expensive than syncing the entries and their children.
Sync without components
Senses are by far the most expensive step. That makes sense, because they're a tree of entities:
Senses
Time syncing senses is fairly evenly divided between: Add, Replace and Remove:

- Add: No specific bottleneck
- Replace: all the time is spend on example-sentences, because that's all we change on existing senses:
- Remove: nothing noteworthy
Sync with components
Almost all the time is spent on Components rather than Complex Forms:
(is that maybe simply, because we sync Components first? They both have to check for reference cycles.)
Components
Adding was by far the most expensive.
Looks like nothing was reordered, which is unexpected.
- Adding: basically all of the time is spent checking for reference cycles or duplicates in the database:
Flamegraph overview
