Re: help wanted reproducing reported performance regression in groff 1.24

"G. Branden Robinson" <[email protected]> Tue, 17 Mar 2026 09:06:31 -0500
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260317140631.5spvkg56zbiezkxn@illithid>
Hi Morten,

At 2026-03-17T13:56:53+0100, Morten Bo Johansen wrote:
> On 2026-03-17 G. Branden Robinson wrote:
> > What libc and libstdc++/libc++ does your system use?
> 
> glibc 2.43+r5+g856c426a7534-1
> libstdc++ 15.2.1+r604+g0b99615a8aef-1
> libc++ 22.1.1-1

Which of these standard C++ libraries is groff linked with on your
system?

For me:

$ ldd $(type -p groff)
        linux-vdso.so.1 (0x00007ffe7df89000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa7659a9000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa765865000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa76584b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa765677000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa765bc2000)

My glibc and libstdc++ are geriatric compared to yours.

libc6:amd64	2.31-13+deb11u13
libstdc++6:amd64	10.2.1-6

> > Can you re-run your test scenario with the `-Z` option added to
> > groff's command line?  I'm curious to know how cutting grotty out of
> > the execution pipeline affects the numbers.
> 
> I used this script:

Hmm, that's dimich's, not mine.

>   for ((n=1; n<=64; n*=2)); do
>   
>       for v in 23 24; do
>         for ((i=1; i<=$n; i++)); do
>           cat bash.1
>         done | troff -M groff-1.$v.0/tmac/ -man -Tutf8 > bash_troff-1.$v.0.ditroff
>       done
>   
>       for v in 23 24; do
>         declare "dur$v"="$(/usr/bin/time -f "%U" grotty < bash_troff-1.$v.0.ditroff 2>&1 > /dev/null)"
>       done
>   
>       printf "% 3s\t% 4s\t% 4s\n" $n $dur23 $dur24
>   done
> 
> Could you modify the script for me to make it do what you want?

I'll have to restructure the script to do that, and inherently change
the measurement being taken.  The script above measures only the time
that grotty takes to render "grout" (".ditroff").  I don't understand
that decision since the problem was purportedly bisected down to a
change in a macro file.  That _can't_ directly affect grotty.

Measuring only grotty's performance might be correct, but it seems like
a premature conclusion to have reached at this point.  It seems to
presume that there's only one site of performance degradation, and where
that site is.

One can wonder if the generated grout files radically differ in size...

$ ls --block-size=K -1s bash_troff-1.2*
55728K bash_troff-1.23.0.ditroff
55728K bash_troff-1.24.0.ditroff

...but they don't.  (That's the final iteration--64 copies of bash(1).)

Anyway, in contrast, my script measured the time consumed by the entire
groff pipeline.  So it's doubly odd that my approach was _more_
performant.  So let me try dimich's script for myself...

...almost 5 minutes later, I can't reproduce the performance degradation
even with an only slightly modified version of dimich's script (the one
you used).

$ bash /tmp/dimich.bash
measuring rendering time of n copies of "/home/branden/share/man/man1/bash.1"
n=1     0.05    0.06
n=2     0.11    0.10
n=4     0.26    0.27
n=8     0.62    0.65
n=16    1.82    1.91
n=32    5.94    5.95
n=64    33.20   33.70
$ cat /tmp/dimich.bash
#!/bin/bash

set -e

bash_man=$(man -w bash)

echo "measuring rendering time of n copies of \"$bash_man\""

for ((n=1; n<=64; n*=2)); do

    for v in 23 24; do
        for ((i=1; i<=$n; i++)); do
            cat "$bash_man"
        done | troff -M groff-1.$v.0/tmac/ -man -Tutf8 > bash_troff-1.$v.0.ditroff
    done

    for v in 23 24; do
        declare "dur$v"=$(/usr/bin/time -f "%U" grotty < bash_troff-1.$v.0.ditroff 2>&1 > /dev/null)
    done

    printf "n=%.2s\t%4s\t%4s\n" $n $dur23 $dur24
done

This observation does nothing to shake my suspicion that the language
runtime fulfilling grotty's demands for dynamic memory allocation is the
culprit here.

But I'm not yet certain.  Please let me know your ldd(1) output above.

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)