diff options
author | Björn Gustavsson <[email protected]> | 2017-12-07 12:16:04 +0100 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2017-12-08 07:11:18 +0100 |
commit | 2fb94bbae9b3ebf6bbd5b0ba3546450036764383 (patch) | |
tree | 29b2ae1ffbe29efc45a90e15b249af419a672fae /lib/tools/doc/html | |
parent | 71bb60815630574bf710b8ce8a7d3b0e48b5a985 (diff) | |
download | otp-2fb94bbae9b3ebf6bbd5b0ba3546450036764383.tar.gz otp-2fb94bbae9b3ebf6bbd5b0ba3546450036764383.tar.bz2 otp-2fb94bbae9b3ebf6bbd5b0ba3546450036764383.zip |
Slightly optimize reading of cooked files in list mode
In general, the new NIF-based file routines are faster than the old
efile driver.
However, on some computers, building the entire OTP system is somewhat
slower. It turns out that it is because 'erlc' cheated by turning off
the IO thread pool (using '+A0') to avoid context switches between
scheduler threads and threads in the IO thread pool. The new file
routines perform IO on dirty IO threads, and there is (by intent) no
way to force the operations to occur on scheduler threads to avoid
the context switches
What we can do to is to use a small (4Kb) read-ahead buffer for files
opened for reading (only) in list mode (which is how the compiler
opens its input files). The buffering reduces the number of context
switches between scheduler threads and dirty IO threads. On my
computer that seems to slightly speed up building of the entire OTP
system.
The buffer should do no harm. The only potential for harm I can
think of is random access to a file opened in read mode, where
the read-ahead buffer could slightly decrease performance. That
does not seems to be a likely use case in practice, though.
Diffstat (limited to 'lib/tools/doc/html')
0 files changed, 0 insertions, 0 deletions