[build-report] Optimise build-report to prevent memory hog over long running builds #148
Conversation
| inputs = []; | ||
| outputs = []; | ||
| entries = []; |
There was a problem hiding this comment.
do we prefer to do = [] or .length = 0? (to use the same array, but clear it, like what we do with the sets .clear() as we aren't redefining new ones with moduleIndex = new Set())
There was a problem hiding this comment.
I was using .length = 0 but I kind of found it a bit hacky and not super explicit.
From what I read online, it's seemingly the same performance either = [] or .length = 0, so I went with the most explicit and comprehensible one.
| // We know it's not a map, so we cast it. | ||
| entryInputs.push(...(outputFound.inputs as Input[])); | ||
| for (const input of outputFound.inputs as Input[]) { |
There was a problem hiding this comment.
why is the cast necessary here?
There was a problem hiding this comment.
In the case of sourcemaps, file.inputs are Outputs as sourcemaps are built out of both Output and Input type of files.
So since I'm checking it's not a sourcemaps earlier, I'm casting it to make the rest of code type error free.
Very much looking for a better way.
What and why?
Running a devserver with webpack/rspack would often (always) end up with a
RangerError: Maximum call stack size exceedederror.How?
The
build-reportwas filling arrays over and over, with each build increasing their size.Now the
build-reportcleans between builds, and keep state in a more efficient way (usingSetandMap).The indexation of modules doesn't log warnings anymore, we mitigate the previous duplication issues by merging differences into the previously indexed module.
Testing covers these changes and remain ✅