This is really more of an OS question than a Go language question. Writing single characters is going to be expensive in any language because you pay the considerable overhead of a system call/user-mode to kernel mode context switch overhead for each character. That is why the C stdio library buffers output. If instead of using fputs you call write directly, you will get similarly slow performance.
The downside of buffering is that sometimes you are already sending large chunks of data and the buffering is slowing you down by adding an unnecessary copy. And sometimes needs to see you'r output immediately. So the C stdio package provides a separate flush function and magically treats files which are connected to terminals differently, flushing them each time it writes a newline character. Go took a simpler, more consistent and explicit approach, where buffering can be added to any writer using the bufio package. It is easy to add it when you need it, but the problem is that you need it most of the time. And people often forget, and then are surprised when their programs spend an inordinate amount of time writing logs, etc. On Monday, 21 December 2020 at 20:56:26 UTC ben...@gmail.com wrote: > > @Ben interesting, I did something similar and also ended up with a 64KB > buffer (seemed like the default of 4KB didn't work very well in my > context). How did you decide of the buffer size? > > I forget how I ended up with 64KB. I think I was doing performance testing > and a buffer larger than the 4KB default was faster, but it started > plateauing at around 64KB (and I didn't want to increase the user's memory > footprint too much). I think I did some basic tests, but it wasn't very > scientific. > > -Ben > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1495f807-8bbb-451d-979c-c4df981f08cfn%40googlegroups.com.
