On Mon, Dec 5, 2016 at 12:51 AM, Michael Forney <mfor...@mforney.org> wrote: > On Sun, Dec 4, 2016 at 11:27 PM, Laslo Hunhold <d...@frign.de> wrote: >> 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%). > > Internally, fgetc/fputc are still using the buffers behind the FILE > structures, so the only overhead I can imagine is due to the repeated > function calls. The previous tail -f code used getline/fputs. We could > fix the NUL byte issue with fwrite instead of fputs, but I'd like to > make sure that it actually makes any noticeable difference before > trying this.
So I think you are correct in that this is actually horribly slow. I think tail should probably be managing its own buffer. I might take a look at what other tail implementations do and play around with this. For now, I think getline/fwrite is the only thing to do since fgets doesn't return the string length, and fputs will stop at the first NUL.
