Re: program gets faster when it outputs more on stderr

[Robert Elz]

    Date:        Sat, 10 Mar 2018 15:46:41 +0100 (CET)
    From:        bashbug@jonkmans.nl
    Message-ID:  <20180310144641.62962CC028D@sint.jonkmans.nl>

First:

  |     Note that when the fast version is ran with 2>/dev/null,
  |     it also performs slowly.

This is not unexpected, and probably unrelated - written that way
the program needs to look up /dev/null and open it, and then close
it again, on every iteration, which neither of the other variants require.

To make it obvious whether there is a difference writing to /dev/null
or stderr,  you should do it like

        exec 3>/dev/null

(in the main program, before anything starts) and then use >&3
in the "sub".

I can't comments much on the real point of your message,
as I don't know the bash code, but ...

  |     When a function is ran in a subshell environment (via backticks),
  |     the program runs faster when that function also writes to stderr.

  |     Expected that, the version writing to stderr would be slower.

You ought also measure and print the CPU time consumed, I expect you'd
find that actually grows (by a small amount) in the "fast" case.

As to the issue - I'd expect some scheduelling/signalling issue, where the
output on stderr causes the parent process (running sub requires a subshell
environment because of the ``) to awaken sooner than it otherwise would,
at that point it detects that the child is done, again sooner than it otherwise
would, and continues with the next iteration.

Why that happens (assuming that is what is happening) someone else
(probably Chet) would need to explain.

Assuming I'm right about why things speed up, then the version using
/dev/null via fd 3 is also likely to not gain from adding the echo - but it
will take an experiment to discover if that is true or not.

kre

ps: the numbers in the output are probably thousandths of a second in a
run, rather than thousands of seconds, 443000 seconds is something like
5 days...