-
Notifications
You must be signed in to change notification settings - Fork 867
Improve performance of circular reference detection #420
Improve performance of circular reference detection #420
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff!
src/schemas/Entity.js
Outdated
} | ||
visitedEntities.push(input); | ||
visitedEntities[id].push(input); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just another implementation thought, no need to act on it:
I wonder if visitedEntities
could be a map structured by key, then id:
visitedEntities = {
[key: string]: { [id: string]: entity }
};
As it is now, entities of the same type are jumbled together if they have the same id
, which kind of just makes it weird if someone were to step through and inspect it with their debugger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I skipped the key
for compactness, but you’re right that would be more explicit. I can make that change if you want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just did it, I hope this can be merged soon now. This causes a big performance hit for us.
* Improve performance of circular reference detection * Use type and id for circular reference lookup
* Improve performance of circular reference detection * Use type and id for circular reference lookup
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Problem
The support for circular references added with #335 comes with a significant performance cost.
For every entity the list of already parsed entities is searched. This leads to non-linear performance characteristics.
Solution
I’ve partitioned the visited entities lookup by ids. Entities with a different type that share the same id will still be added to a list, which shouldn't be a problem in practice. Using a Set would have been simpler, but that was ruled out earlier.
Performance comparison
Setup
Normalization times in milliseconds for 5 runs
TODO