Improve performance of collection methods in entity adapters #440
Conversation
Prior to this fix, collection methods in sorted_state_adapter ran in quadratic time, because they iterated over the collection with single-item mutators, each of which also running in linear time. Now, we first collect all modifications (each in constant time), then sort them in linearithmic time, and finally merge them with the existing sorted array linearly. As a result, we can improve performance of collection methods to N + M log M, where N is the number of existing items and M is the number of modifications. Single-item methods are now expressed through those for collections, still running linearly.
…_adapter Removing "holes" created by updateManyMutably() should be there instead of merge().
It should return "true" unconditionally (probably worth a test).
These methods ran in quadratic time by interating over the collection and applying a linear algorithm for each item. Now, we modify entity hashes first (each in constant time), and then update the array of their ids in linear time. As a result, all operations now occur linearly. We also simplified logic for single-item operations by expressing them through those for collections. The removal methods also apply to sorted collections (because they preserve their order).
dinvlad
changed the title
CircleCI failed the build because includes() is not supported by its runtime yet. We use an alternative syntax to fix that.
|
Thanks @dinvlad! |
|
Glad to help! Something I haven't addressed is if an entity is updated with a new ID (as determined by
To prevent that, we could However, this case prompts the question: should such updates be considered legal in the first place? After all, they modify multiple entities with a 'single' update and it may not be clear which update should take precedence (imagine doing multiple of these at the same time). |
Prior to this fix, collection methods in sorted_state_adapter
ran in quadratic time, because they iterated over the collection
with single-item mutators, each of which also running in linear time.
Now, we first collect all modifications (each in constant time),
then sort them in linearithmic time, and finally merge
them with the existing sorted array linearly.
As a result, we can improve performance of collection methods
to N + M log M, where N is the number of existing items
and M is the number of modifications.
Single-item methods are now expressed through those
for collections, still running linearly.
EDIT: Also updated methods for unsorted collections:
These methods ran in quadratic time by interating over
the collection and applying a linear algorithm for each item.
Now, we modify entity hashes first (each in constant time),
and then update the array of their ids in linear time.
As a result, all operations now occur linearly.
We also simplified logic for single-item operations
by expressing them through those for collections.
The removal methods also apply to sorted collections
(because they preserve their order).
Relevant discussion: #421