aboutsummaryrefslogtreecommitdiffstats
path: root/lib/tools/doc/html
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2017-12-07 12:16:04 +0100
committerBjörn Gustavsson <[email protected]>2017-12-08 07:11:18 +0100
commit2fb94bbae9b3ebf6bbd5b0ba3546450036764383 (patch)
tree29b2ae1ffbe29efc45a90e15b249af419a672fae /lib/tools/doc/html
parent71bb60815630574bf710b8ce8a7d3b0e48b5a985 (diff)
downloadotp-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