in reply to Re: SLOW DOWN, you move too fast.....
in thread SLOW DOWN, you move too fast.....

... except that, as far as any of us can tell from the code, it prints to standard output (line buffered by default) and includes a newline. Even if all of the variables in that line are empty, this will still print at least 4654 characters, which is larger than most default standard output buffers I've seen in use (and the user is seeing at least some output).

Unless there's an IO layer somewhere with a very weird buffering behavior, I see no possible way this could have anything to do with buffering. print calls to STDOUT attached to a terminal and including a newline almost never have buffering problems.

  • Comment on Re^2: SLOW DOWN, you move too fast.....

Replies are listed 'Best First'.
Re^3: SLOW DOWN, you move too fast.....
by ikegami (Patriarch) on Aug 09, 2006 at 02:12 UTC

    First, you have no way of knowing how many bytes were printed, so you have no idea if the number of bytes is a multiple of a reasonable buffer size. How then can you claim the buffering is weird?

    Second, the number of bytes that didn't print is even more telling. Could 73 lines fit in a normal buffer? Probably.

    Thirdly, why do you assume he's printing to a tty? To count the lines exactly, he probably redirected stdout. That disables line buffering.

    Finally, that a line was only partially printed is a very good indicator of a buffering problem.

[reply]
      ...you have no way of knowing how many bytes were printed...

      I gave the minimum lower bound.

      Second, the number of bytes that didn't print is even more telling.

      I repeat your first assertion. How do you know the number of bytes that didn't print?

      Thirdly, why do you assume he's printing to a tty?

      In the absence of any other information, what else is there to assume?

      To count the lines exactly, he probably redirected stdout. That disables line buffering.

      The OP had to notice the problem before deciding to count the lines exactly. There's no way of knowing without more information. You might as well assume $|++ somewhere in the program.

      Finally, that a line was only partially printed is a very good indicator of a buffering problem.

      ...or unexpected data, such as \r or \b characters.

[reply]
[d/l]
[select]

        Why are you trying so hard to prove that buffering is not a possibility? Maybe you should be spending your efforts on finding alternate causes if you think it's not buffering.

        I gave the minimum lower bound.

        If the buffer fills up once, there will be X bytes outputed. If the buffer fills out twice, there will be 2X bytes outputed. If the buffer fills out three times, there will be 3X bytes outputed. etc. The only time the minimium lower bound on the numer of bytes actually printed matters if it's lower than a reasonable X. 512, 1024, 4096 bytes are all reasonable Xs, so that's not the case here.

        If you wanted to show weird buffering, you'd have to show the exact number of bytes printed is not a multiple of a reasonable X. The minimium lower bound on the numer of bytes actually printed is totally useless to this end.

        How do you know the number of bytes that didn't print

        I don't. But I didn't make claims of weird buffering.

        In the absence of any other information, what else is there to assume?

        Who says you should make an assumption? And if there's truly no other information, you could always assume the opposite.

        ...or unexpected data, such as \r or \b characters.

        That would give the appearance of *starting* halfway, not *stopping* halfway.

[reply]

In Section Seekers of Perl Wisdom