Re: print stdout and flush

[Jay Carlson <nop@...>]

On Thu, May 26, 2011 at 9:28 AM, Cuero Bugot <cbugot@sierrawireless.com> wrote:
> I may be re-spawning an ancient topic but I was not able to retrieve clear explanation/reasons on the history.
>
> I am wondering why static int luaB_print (lua_State *L) function does not have a fflush(stdout) after fputs("\n", stdout);
> 1) For the specific use case of print (mainly debug) I would not consider armful in term of performances.

I would bet a lot of people use print() in ways that are not about
debug; print() shows up a lot in my ad-hoc Unix-y pipes/scripts. It
would be a significant performance hit.

If there is a desire for a real debug function, it would be more
natural for output to go to io.stderr. Might not be a bad idea anyway;
log()?

> 2) It would also be more user friendly (who did not try to redirect stdout and miss a couple of lines because of the buffering)

Me? I guess I don't understand the situation in which this would happen.

Performance difference between buffered and unbuffered access for file
redirection is significant. Calling print() on a 40 character string a
million times going to a ramdisk currently takes:

ubuntu@ubuntu:~$ /usr/bin/time lua foo.lua >/tmp/aa
0.73user 0.15system 0:01.10elapsed

Turning off buffering with setvbuf takes

ubuntu@ubuntu:~$ /usr/bin/time lua foo.lua >/tmp/aa
1.80user 2.32system 0:05.43elapsed

> 3) Finally it would also 'comply' or at least mimic the C ISO/Posix printf API that recommends to flush the buffer when '\n' is printed.

Cite?

> Is there a rationale that I am missing here ?

print() currently acts like C's printf(). This seems natural for a
language that generally takes C's position on IO (much to the dismay
of the i18n crowd, for instance.)

Jay