fs: use sized reads for large files in readFileUtf8 - #65328
Open
codebytere wants to merge 1 commit into
Open
Conversation
fs.readFileSync(path, 'utf8') read the whole file in 8 KiB read() calls appended to a std::string, i.e. one syscall and a potential reallocation per 8 KiB (an 8 MiB file took ~1400 read() calls). Keep the exact old sequence for small files (one read into the 8 KiB stack buffer, one read reporting EOF). Once a read fills the stack buffer, read the rest directly into one heap buffer sized from fstat() (plus one byte so that the EOF read does not force growth), growing geometrically only when the size is unavailable or wrong. The size is only an allocation hint: reading continues until read() reports EOF, so procfs/sysfs files, FIFOs, files that change while being read and file descriptors positioned mid-file behave as before, and the bytes handed to StringBytes::Encode() are exactly the ones read. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>
This file contains hidden or 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
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.
fs.readFileSync(path, 'utf8')gets +19…42 % on 4 MiB files and +60…231 % on 256 KiB files, with small files untouched, byreading large files into one right-sized buffer instead of 8 KiB at a time.
(Linux x64, 30 runs. A 300 KB file goes from 39 syscalls to 5.)
ReadFileUtf8— behindreadFileSync(…, 'utf8')and therefore every CommonJS module load — read in 8 KiBread()s,appending each to a
std::string. Files that fit the first 8 KiB read behave exactly as before. Once a read fills the stackbuffer, the rest goes straight into one heap buffer: a 64 KiB step first (so files up to 64 KiB take the same reads as today
and no
fstat), then sized fromfstat()if that fills too, with geometric growth as the fallback. The size is only anallocation hint — reading continues until
read()returns 0, so procfs/sysfs and concurrently changing files behave asbefore and
StringBytes::Encode()sees exactly the bytes read. Allocation failure throwsERR_MEMORY_ALLOCATION_FAILED.Tests:
test-fs-readfilesync-utf8-sizes.js(new): equalsreadFileSync(path).toString('utf8')around every internalboundary (0 … 8 MiB+5) with multi-byte characters straddling chunk edges; by fd from start / at EOF / mid-file; binary input;
/proc/self/mapsand friends; EISDIR. fs, module and require suites pass.Disclosure: the code, test, measurements and this description were written by Claude Code, directed and reviewed by @codebytere.