On Sun, 4 Dec 2016 21:55:02 -0800
Michael Forney <mforney_AT_mforney.org> 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 <dev_AT_frign.de>
Received on Mon Dec 05 2016 - 08:27:06 CET