You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently discovered that invoking buffer() on a ConcatSource incurs a massive performance overhead by invoking Buffer.concat, particularly if there are layers of CachedSource -> ConcatSource -> CachedSource -> ConcatSource.
Invoking source() and the calling Buffer.from is considerably faster because it avoids the intermediary allocations.
We have writev nowadays, so there's no reason we couldn't keep the data as Buffer[] all the way until the final write to the file system and avoid repeated copying of memory during the concatenation layers.
The text was updated successfully, but these errors were encountered:
@dmichon-msft I see, do you want to send a PR (we can keep old buffer() and mark them as deprecated plus implement a new sourceBuffer(), maybe a better name?)? But honestly I don't think we have a lot of buffer() calls inside webpack (and official plugins), but non official can use it.
Also can we try to bench it using different size and nesting with source() and Buffer.from(), and buffer(), will be interesting to look at this
I recently discovered that invoking
buffer()
on aConcatSource
incurs a massive performance overhead by invokingBuffer.concat
, particularly if there are layers ofCachedSource
->ConcatSource
->CachedSource
->ConcatSource
.Invoking
source()
and the callingBuffer.from
is considerably faster because it avoids the intermediary allocations.We have
writev
nowadays, so there's no reason we couldn't keep the data asBuffer[]
all the way until the final write to the file system and avoid repeated copying of memory during the concatenation layers.The text was updated successfully, but these errors were encountered: