feat: adds the strict resolver as an option#837
Open
gabrielcsapo wants to merge 9 commits intoember-cli:mainfrom
Open
feat: adds the strict resolver as an option#837gabrielcsapo wants to merge 9 commits intoember-cli:mainfrom
gabrielcsapo wants to merge 9 commits intoember-cli:mainfrom
Conversation
chriskrycho
suggested changes
Dec 19, 2022
Contributor
chriskrycho
left a comment
chriskrycho
left a comment
There was a problem hiding this comment.
First-pass review on just the README changes; I'll get to the actual implementation bit (which I assume is just inlined directly from the existing package, so I don't expect to want changes there!) later today or tomorrow!
README.md
Outdated
Comment on lines
49
to
56
| _For additional improvements when fully using the ember-strict-resolver monkey patching the registry to no longer cache and simply returning the values passed like the following can be produce extra performance._ | ||
|
|
||
| ```js | ||
| // disable the normalization cache as we no longer normalize, the cache has become a bottle neck. | ||
| Ember.Registry.prototype.normalize = function (i) { | ||
| return i; | ||
| }; | ||
| ``` |
Contributor
There was a problem hiding this comment.
However, I have a broader comment, which is: if we think this is worth doing, we should build a public API for it. It's one thing to do this as an experiment in our app (a successful one, I might add!) but we should not recommend others do it until there is a public API, or else we're setting people up for pain.
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Originally from https://github.com/stefanpenner/ember-strict-resolver we have been using this in production for a few years! It is faster and less prone to errors as it doesn't allow configuration.
It would be great to support this as a first class resolver.
Details
When debugging how often we call into the resolver to access values from the registry, on an initial page load of linkedin feed we access the registry ~11,800 times.
When running linked.com feed using the ember-strict resolver we see in the experiment over ~300ms faster The differences are:
boot phase estimated difference -188ms [-195ms to -181ms]
transition phase estimated difference -42ms [-57ms to -27ms]
render phase estimated difference -23ms [-37ms to -9ms]