Skip to content
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

Drop per-pipeline transformation cache #9459

Merged
merged 5 commits into from
Jan 5, 2024
Merged

Conversation

devongovett
Copy link
Member

This was extracted from the db2 branch. As discussed in previous core team meetings, this removes the per-pipeline transformation cache. This is only hit when:

  • The file was "touched" in some way that triggers the watcher to invalidate it, but the content didn't actually change. For example you hit save without making changes.
  • You changed the content of an asset, and then changed it back. Could happen when switching between branches.
  • The content of a config file (e.g. package.json) changed in a way that didn't actually affect the config contents (e.g. different key). This is perhaps the most likely scenario.

Other cases are already handled by the request graph which won't even run an asset request that isn't invalidated.

Given the limited cases where it would be hit, the transformation cache results in a lot of complexity and issues. It is difficult if almost impossible to compute the cache keys for transformations ahead of time. You need to know all of the files, configs, dev dependencies, options, environment variables, etc. that will be used when doing a build for an asset, all of which require the request graph to know, so the transformation cache couldn't even be used standalone. In addition there were some bugs because it's hard to associate each of these to the correct plugins, especially dev dependencies which are be loaded on demand. For these reasons, we decided to remove the transformation cache and just rely on the request graph to know when to rebuild.

One other benefit of this change is that each asset only has one key in the cache now, whereas previously the cache would grow unbounded as changes were made.

In the future perhaps we can find other ways to address the above cases if we find this change results in widespread performance regressions.

@devongovett devongovett mentioned this pull request Jan 3, 2024
4 tasks
@mischnic
Copy link
Member

mischnic commented Jan 3, 2024

AFAICT, Asset.hash is completely unused now (only set and never actually read)

hash: ?string,

@devongovett devongovett merged commit 2d40ce5 into v2 Jan 5, 2024
13 of 16 checks passed
@devongovett devongovett deleted the remove-pipeline-cache branch January 5, 2024 15:52
@bb010g
Copy link

bb010g commented Jan 8, 2024

Does this effect the caching impact of babel.config.js compared to babel.config.json?

@devongovett
Copy link
Member Author

No. JS files are still harder to cache because they can produce non-deterministic results, and we have to take into account all of the dependencies they import/require etc.

lettertwo added a commit that referenced this pull request Jan 30, 2024
* upstream/v2: (22 commits)
  Add source map support to the inline-require optimizer (#9511)
  [Web Extension] Add content script world property to manifest schema validation (#9510)
  feat: add getCurrentPackageManager (#9505)
  Default Bundler Contributor Notes (#9488)
  rename parentAsset to root for msb config and remove unstable (#9486)
  Macro errors -> v2 (#9501)
  Statically evaluate constants referenced by macros (#9487)
  Multiple css bundles in Entry bundle groups issue (#9023)
  Fix macro issues (#9485)
  Bump follow-redirects from 1.14.7 to 1.15.4 (#9475)
  Revert more CI changes to centos job (#9472)
  Use lightningcss to implement CSS packager (#8492)
  Fixup CI again (#9471)
  Clippy and use napi's Either3 (#9047)
  Upgrade to eslint 8 (#8580)
  Add support for JS macros (#9299)
  Fixup REPL CI (#9467)
  Drop per-pipeline transformation cache (#9459)
  Upgrade some CI actions (#9466)
  REPL (#9365)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants