On Sun, 4 Dec 2016 21:55:02 -0800 Michael Forney <[email protected]> wrote:
Dear Michael, > I finally got around to addressing the issues with fread I raised at > the end of http://lists.suckless.org/dev/1504/26580.html. > > This patch series eliminates several uses of fread/fwrite where plain > read/write are more appropriate. To help with the common case of > writing an entire buffer to a file descriptor, I added a writeall > function (which works similar to plan9's standard write function and > the Write/write_all functions in go/rust). All users of concat were > better suited to work on plain file descriptors except for tail, so I > switched concat to a read/writeall loop, and tail to use a > fgetc/fputc loop. fgetc/fputc really can slow down your program, which I noticed when I wrote farbfeld-filters. Working on a buffer-basis rather than a char-by-char-basis really speeds up things a lot (for me it was around 50%-70%). Can you provide some performance-information e.g. for cat(1)? Does it get any faster with the writeall()-loop? What other benefits do we see here? Can you elaborate in this thread again why we should do raw I/O? In a naïve sense, the operating system can "shedule" reads and writes more efficiently with the buffered I/O. > The result should be more efficient (no copy between read/write > buffers, and data is processed as it comes in), and is roughly the > same complexity as before. In most cases, we now pull in less of > stdio, so statically linked binaries get smaller. Additionally, > cat/tee on a pipe/terminal is now usable. That makes sense. > Along the way, I found and fixed several bugs, mostly dealing with > error checking. > I've been running with these patches for a couple days now and > haven't noticed any regressions. That is great! I'm glad you test your patches before submitting, which I have been guilty of neglecting for so many times. Cheers Laslo -- Laslo Hunhold <[email protected]>
