introduce cacheKeyForTree to avoid running treeForX multiple times #421
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.
We have a big monorepo and got to a point, where our build times are unacceptably slow. Can easily be 2-3mins to start an app. We've started to do some investigation to try and figure our what might be an issue.
cacheKeyForTree
and this RFC sparked my interest. After adding cache for all our internal addons, we've got in some cases up to 50% speed up. Next on our list is to identify all community addons that might be missing caching.ember-cli-babel
is more/less the first one, as it might have quite a big impact.Will use this command to show difference before an after
Log before adding a cache
393 lines of cache opt-out.
Build successful (135792ms)
Show output
Log after adding a cache
84 lines of cache opt-out.
Build successful (101886ms)
Show output
After this change, we've got
30% increasesome increase (after more extensive testing) in initial build time. We'll try to measure when/if we'll get to zero cache-miss.I am curious to ask for feedback and see if we are good to move with that cache key addition?
As a side note:
Seems like a lot of addons that we use don't implement
cacheKeyForTree
, maybe it is not well knows for addon authors? Feels like some internal lint for ember-cli(?-babel) for addons could be useful, and that addon authors have to explicitly tell, that they don't need the cache, rather than be in the dark that by adding treeForX they've opted out of cache.