-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v2.1 cache #8122
v2.1 cache #8122
Conversation
this PR replaces #5931 |
Asset Size Report for 36340c8 Modern Builds 🛑 The size of the library EmberData has increased by +3.34 KB (+551.0 B compressed) which exceeds the failure threshold of 75 bytes.WarningsChangeset
Full Asset Analysis (Modern)
Modern Builds (No Rollup) ☑️ EmberData has not changed in sizeIf any packages had changed sizes they would be listed here. Changeset
Full Asset Analysis (Modern)
|
Performance Report for 36340c8 Scenario - basic-record-materialization: ☑️ Performance is stable
Scenario - relationship-materialization-simple:
|
48c535c
to
1030357
Compare
…nager + singleton cache. Feels pretty achievable this week
…e ~15x faster (3s => 200ms)
a897b3a
to
836a38c
Compare
Performance (and size) will get worse before they get better for this feature. Since we have to wrap every single RecordData in a unique manager so long as V1 exists, I would expect this to initially negate a significant portion of the (sizeable) improvements from the simplification work and removal of InternalModel.
However!
Since the fully v2 cache world is capable of being a singleton (and our implementation will be so), once v1 is not in the system we drop from 2N classes to support N records in the cache to two class instances (total). It is at that point I would expect to see us regain double what we lost from adding in the manager.
My hope is that we can produce a mechanism such that an app may signal that V1 is not in use, which our standard build infra will then make use of to remove the expensive codepath and utilize the cheap one. Ideally this will all be in place prior to merging this PR.
Release Notes
The singleton cache and singleton manager are currently both behind feature flags, only singleton cache is activated (since this is our own implementation this is easier for us to achieve with some safety).
A follow up PR to this one will activate singleton manager as well as document the v2 cache format and deprecate the v1 cache format.
While studying the cost centers of the various benchmarks I came away with the following observations (once singleton-manager is activated)
(1) and (3) are respectively cost centers that will be significantly improved as we see through the plan for 5.0, as eliminating EmberObject / ArrayProxy from the equation will simplify this significantly.
(2) requires rebooting and finishing #7521 with the additional observation that we should eliminate the classes used to hold state for each edge as they are largely dumb containers at this point.