Excess RewritePackageJson trees observed

When building a large app, with many nested addons we have observed excess RewritePackageJSON tree’s.

Observed in the wild, rather than 9,933 broccoli nodes, we see in excess of 87,000 nodes.

This appears to severely impact build performance.

I believe, the fix may be that v2Trees creation of it’s new RewritePackageJson to go through throughTreeCache if possible.

It may also be the case, that the entire result of v2Tree should in some circumstances go through the cache as well.

[tmquinn]

Starting on this…

[ef4]

Sigh. Yes, ember-cli’s super-linear build costs as the number of addons grows strikes again.

I know @stefanpenner knows this already, but for interested readers: ember-cli doesn’t just build each addon, it builds each addon for each time that addon is consumed by another package (meaning the app or another addon). This causes build costs to grow super-linearly as you add more addons and they depend on each other. Embroider’s compat layer faithfully reproduces this expensive behavior because it has to. Whereas our new V2-formatted addons skip all that and build costs grow linearly in the number of addons, rather than super-linearly.

I agree, we can run the whole v2Tree through throughTreeCache, making a new embroider-specific category for it that won’t collide with any existing category.

This would be a good PR for you or someone on your team, because you should be able to see an immediate performance impact in that giant app.