perf: improve build times and memory utilization #14016
Merged
Conversation
This file contains 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
Technically this is also covered by a fresh install / lock-file maintenance, but I thought it might be good to call it out with a specific change-log notification. On my own projects, I've seen around 28% faster builds, with a 1.3 GB (36.6%) reduction in peak memory usage. Which should hopefully help with vitejs#2433 Rollup 3.27.1 contains a change (rollup/rollup#5075) that improves sourcemap handling for rollup builds. These improvements seem to have the most impact where there is large amounts of treeshaking since sourcemaps are no longer being decoded in memory for files that are tree-shaken from the final bundle, but it also releases those decoded mappings arrays when they are no longer needed which frees up more memory during render chunks. It also reduces memory usage and build times for projects that don't set `build.sourcemaps: true` in their vite config. For those projects, any sourcemaps loaded from dependencies in node_modules, etc, were being decoded proactively in the event rollup needed to trace the sourcemap to find the locations for any warnings/errors. Now that process only happens if they are needed, and a fair amount of processing and allocations can be avoided.
|
|
|
/ecosystem-ci run |
|
📝 Ran ecosystem CI: Open
|
|
The fails also exist in |
bluwy
approved these changes
Aug 3, 2023
bluwy
changed the title
|
@bluwy Looks like it got reverted in 3.27.2 until rollup/rollup#5087 gets merged. So I'll need to bump the version again whenever that release goes out as this PR will currently resolve to 3.27.2 and not pick up this change. |
|
No problem, feel free to send a follow-up PR 👍 |
9 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
Technically this is also covered by a fresh install / lock-file maintenance, but I thought it might be good to call it out with a specific change-log notification.
On my own projects, I've seen around 28% faster builds, with a 1.3 GB (36.6%) reduction in peak memory usage. Which should hopefully help with #2433
Rollup 3.27.1 contains a change (rollup/rollup#5075) that improves sourcemap handling for rollup builds.
These improvements seem to have the most impact where there is large amounts of treeshaking since sourcemaps are no longer being decoded in memory for files that are tree-shaken from the final bundle, but it also releases those decoded mappings arrays when they are no longer needed which frees up more memory during render chunks.
It also reduces memory usage and build times for projects that don't set
build.sourcemaps: truein their vite config. For those projects, any sourcemaps loaded from dependencies in node_modules, etc, were being decoded proactively in the event rollup needed to trace the sourcemap to find the locations for any warnings/errors. Now that process only happens if they are needed, and a fair amount of processing and allocations can be avoided.Additional context
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123).