Slow Rollup-family load for framework binaries
Problem
In build mode, the Rollup-family load hook matches *.wasm|*.dat|*.pdb, readFiles the full file into a Buffer, and emitFiles it. Large .NET wasm assets dominate plugin build time in bundler timing logs.
Dev/serve avoids this (export default '/_framework/…' + middleware).
[PLUGIN_TIMINGS] Your build spent 88% of 3.4s inside plugin hooks (3.0s).
Measured inside the callback, so queue time is excluded and time the callback itself awaited is not:
- unplugin-dotnet-wasm buildStart (83%, 2.8s, 1 call)
Those rows are 83% of the build; the rest of the 88% is below.
Not measurable — 1 hook whose calls overlap, so elapsed time covers work other calls were doing. Profile with `node --cpu-prof`:
- unplugin-dotnet-wasm load (207 calls)
See https://rolldown.rs/reference/InputOptions.checks#plugintimings for more details.
Constraint
Assets are typically out of tree. Rollup has no “emit by path” API, emitFile always needs source bytes.
Options
- Hand off to bundler asset pipeline: stop handling binaries in
load; let Vite/Rollup native new URL / asset plugins emit them. Not a one-line filter remove: Vite currently gets @vite-ignore on those new URLs, and serve’s /_framework/… export lives in the same hook.
writeBundle copy + literal URL: load exports a final URL string; copy files into outDir later. Rollup never re-resolves the wasm (unless you import / tracked new URL it). Tradeoff: own hashing/base/naming.setAssetSource deferral: still reads fully; only moves cost out of load timing.
Option 1 is preferred atm.
Slow Rollup-family
loadfor framework binariesProblem
In build mode, the Rollup-family
loadhook matches*.wasm|*.dat|*.pdb,readFiles the full file into aBuffer, andemitFiles it. Large .NET wasm assets dominate plugin build time in bundler timing logs.Dev/serve avoids this (
export default '/_framework/…'+ middleware).Constraint
Assets are typically out of tree. Rollup has no “emit by path” API,
emitFilealways needssourcebytes.Options
load; let Vite/Rollup nativenew URL/ asset plugins emit them. Not a one-line filter remove: Vite currently gets@vite-ignoreon thosenew URLs, and serve’s/_framework/…export lives in the same hook.writeBundlecopy + literal URL:loadexports a final URL string; copy files intooutDirlater. Rollup never re-resolves the wasm (unless youimport/ trackednew URLit). Tradeoff: own hashing/base/naming.setAssetSourcedeferral: still reads fully; only moves cost out ofloadtiming.Option 1 is preferred atm.