dtrace output performance

From: Chuck Silvers <chuq_at_chuq.com>
Date: Thu, 03 Feb 2022 01:04:53 UTC
I've got a dtrace script that logs a bunch of output, so much that
the dtrace process can't keep up with the data produced by the kernel
and so a bunch of output is dropped.  I noticed that the dtrace process
is doing tiny little writes to the output file, which I traced back to this
call to fflush() in dt_printf():


        va_copy(ap2, ap);
        n = vfprintf(fp, format, ap2);
        fflush(fp);
        va_end(ap2);


This fflush() call was never in solaris, it was added to freebsd in this commit:

commit b29602e4d83ed64fedb0cd0b0b7f257c35f8363c
Author: John Birrell <jb@FreeBSD.org>
Date:   Sat Apr 26 04:33:15 2008 +0000

    * Get the maximum number of CPUs via a sysctl.
    * Handle the different ioctl design.
    * Support the freopen() changes.
    * Use functions in FreeBSD's process library rather than the CDDL
      library that Solaris has which sits on top of their process file
      system and is therefore unsuitable for use on FreeBSD. The libproc
      API for FreeBSD is deliberately different to that on Solaris because
      Sun wouldn't release the libproc.h header under a BSD license.



It's not at all obvious from that description why the fflush() might be needed,
possibly it's related to the freopen thing?  If it's not that then I suspect that
it's not actually necessary and probably just a debugging leftover, and
I'd like to remove it.  Does anyone know of any reason to keep this fflush()?

Removing this fflush() reduces the dtrace process CPU usage in my test from 100%
down to 13%, and no more trace output is lost.

-Chuck