4 ms·
strace tip #31415927: If your program is I/O bound, sometimes you can improve performance by increasing the size of the read buffer. A bigger buffer means few
by minimax 15y ago
strace tip #31415927: If your program is I/O bound, sometimes you can improve performance by increasing the size of the read buffer. A bigger buffer means fewer system calls and potentially increased performance. How do you know how big the read buffer is? Sometimes it's hard to tell even if you have the source (i.e. you're using stdio). With strace you can see the number of bytes you're trying to slurp in with each read system call. If it looks like a small number, you can then go figure out how to make it a bigger number, perhaps using setvbuf or rolling your own buffered I/O.
- dap 15y agoYes, buffer size can have a significant effect on performance. You can quickly see buffer sizes used by "read" across your system with "dtrace -n 'syscall::read:entry{ @ = quantize(arg2); }'", which summarizes the output (in case you're doing more of these than you can reasonably see in the console) and has significantly less impact on the program you're tracing. Output for my system: value ------------- Distribution ------------- count 0 | 0 1 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1278 2 | 0 4 | 0 8 | 0 16 | 0 32 | 0 64 | 0 128 | 0 256 | 0 512 | 1 1024 | 0 2048 |@ 20 4096 | 2 8192 | 0 16384 | 0 32768 | 0 65536 | 3 131072 | 2 262144 | 1 524288 | 0 and if you want to know where, say, the 512-byte reads are coming from: # dtrace -n 'syscall::read:entry/arg2 == 512/{ @[ ustack() ] = count(); }' mdworker libSystem.B.dylib`read+0xa Foundation`-[NSConcreteFileHandle readDataOfLength:]+0x1d6 RichText`GetMetadataForURL+0x338 mdworker`0x100006a66 mdworker`0x100009ec1 libSystem.B.dylib`_pthread_start+0x14b libSystem.B.dylib`thread_start+0xd 1