Performance regression of man pages rendering after groff update

dimich · 2026-03-08 05:56:20

I noticed a bigger delay in man pages rendering after groff update to 1.24.0. For example,

groff-1.23.0-8:

$ time MANPAGER='' man xterm > /dev/null 

real    0m0.356s
user    0m0.523s
sys     0m0.064s

groff-1.24.0-2:

$ time MANPAGER='' man xterm > /dev/null 

real    0m0.547s
user    0m0.712s
sys     0m0.077s

I intentionally found a man page large enough but without "CW font" warning as an example. Some other man pages I often read, e.g. gcc(1) and bash(1) produce a lot of "cannot select font 'CW'" warnings which may affect measurement result. Anyway,

groff-1.23.0-8:

$ time MANPAGER='' man gcc > /dev/null
troff:<standard input>:36434: warning: cannot select font 'CW'
 -//-

real    0m1.358s
user    0m2.139s
sys     0m0.139s

groff-1.24.0-2:

$ time MANPAGER='' man gcc > /dev/null
troff:<standard input>:36434: warning: cannot select font 'CW'
 -//-

real    0m2.245s
user    0m2.933s
sys     0m0.344s

I understand that delay is not such a big problem and a matter of used to, but it's very annoying.
I would like to know Arch's community opinion, does it worth to report upstream? Is anyone else noticing this delay?
Any suggestions how to properly measure groff performance to present it in upstream ticket?

Last edited by dimich (2026-03-08 05:57:35)

seth · 2026-03-08 08:22:15

Unmotivated performance regressions would count as a bug, unfortunately https://cgit.git.savannah.gnu.org/cgit/ … /ChangeLog is 25k lines, spanning > 2 years
There's ample opportunity for motivated performance regressions (feature, bug fix/correctness)

Therefore

I would like to know Arch's community opinion, does it worth to report upstream?

effectively translates to "Do you want to bisect groff?"

dimich · 2026-03-08 09:33:07

seth wrote:

"Do you want to bisect groff?"

Thank you for fast reply.
Yeah, the first thing I did was naive try to look which commit might have caused the regression I'm thinking about automating bisection but not familiar with GNU document formatting system. Execution time of man command doesn't seem to be a good measure. I would like to synthesize some larger input text and feed it to groff directly. Any hints what format of that text should be to make groff to do the same kind of transformation what it does for man?

seth · 2026-03-08 13:59:32

Execution time of man command doesn't seem to be a good measure.

Why not? You get 50% longer execution - run that three times and check the average.

The open risk is that this might not be one commit but the addition of many small performance hits.
Despite the 2113 commits (jeez…) it should only be 11-12 bisection tests, you don't really need to automatize that?
If you want to avoid using "man", here's a man-cheat to use man.archlinux.org if you don't want to waste space on mandb

#!/bin/bash

export GROFF_TMPDIR=/tmp
cd /tmp # GROFF_TMPDIR seems ignored
#curl -sL "https://man.archlinux.org/man/$1.raw" | groff -t -Thtml -mandoc
#exit

if [[ "$1" = "2html"  ]]; then
    shift
    unset GROFF_NO_SGR
    curl -sL "https://man.archlinux.org/man/$1.raw" | groff -t -Thtml -mandoc
#    curl -sL "https://man.archlinux.org/man/$1.raw" | groff -t -Tutf8 -rLL=128n -rLT=128n -mtty-char -mandoc
    exit
fi

TTY="$(tty)"
if [[ "$TTY" = "/dev/pts/"* ]]; then
unset GROFF_NO_SGR
    read ROWS COLS < <(stty -F "$TTY" size)
    curl -sL "https://man.archlinux.org/man/$1.raw" | groff -t -Tutf8 -rLL=${COLS}n -rLT=${COLS}n -mtty-char -mandoc | ansifilter -H -r ~/.local/share/qiq/ansifilter.css #less -r -Ps"manual\: $@ \| %dm"
    exit
fi

dimich · 2026-03-08 15:24:36

seth wrote:

Why not? You get 50% longer execution - run that three times and check the average.

I didn't want to figure out how to compose MANROFFSEQ to make man to use custom groff binary instead of /usr/bin/groff. Anyway, the issue is reproducible just by feeding uncompressed man page to groff.

seth wrote:

it should only be 11-12 bisection tests, you don't really need to automatize that?

Single clean build takes about 3 minutes on my system. So I have to spend up to half of hour distracting every 3 minutes to run test, check result and move bisect on. I'd rather spend a few of hours setting up the environment but run it once

seth wrote:

here's a man-cheat to use man.archlinux.org

Thanks. For now I concatenated a man page multiple times and feed it to groff with the same options as man do.

seth wrote:

The open risk is that this might not be one commit but the addition of many small performance hits.

Interestingly, with groff-1.23.0-8 processing time depends on file size clearly linearly. With groff-1.24.0-2 it looks like quadratic or exponential.

kokoko3k · 2026-03-08 15:40:41

Maybe ccache would speedup the process enough?

seth · 2026-03-08 16:02:26

Why would one go for a "clean build" on bisection anyway?
However whether this is automatized or not is really a matter of preference - my gut feeling would be that the manual run ends up being faster than writing a bisection + test script but if my heart was weighted with every single borderline pointless (or not - there's the learning aspect) script I wrote, Ma'at better brings the lead-based feather )

dimich · 2026-03-08 16:34:14

kokoko3k wrote:

Maybe ccache would speedup the process enough?

Maybe. However, build time is not a big concern. 1.23.0 tag is failing to build on my system.

$ make                                                                                                                                                                                                                
  GEN      lib/alloca.h                                                                                                                                                                                                                        
  GEN      lib/inttypes.h                                                                                                                                                                                                                      
  GEN      lib/limits.h                                                                                                                                                                                                                        
  GEN      lib/math.h                                                                                                                                                                                                                          
  GEN      lib/stdio.h                                                                                                                                                                                                                         
  GEN      lib/stdlib.h                                                                                                                                                                                                                        
  GEN      lib/string.h                                                                                                                                                                                                                        
  GEN      lib/sys/types.h                                                                                                                                                                                                                     
  GEN      lib/unistd.h                                                                                                                                                                                                                        
  GEN      lib/unitypes.h                                                                                                                                                                                                                      
  GEN      lib/uniwidth.h                                                                                                                                                                                                                      
  GEN      lib/wchar.h                                                                                                                                                                                                                         
  GEN      lib/wctype.h                                                                                                                                                                                                                        
echo 1.23.0 > .version-t && mv .version-t .version                                                                                                                                                                                             
  GEN      contrib/chem/README                                                                                                                                                                                                                 
  GEN      doc/groff.info

...

./groff.toc:199: Undefined control sequence.
l.199 @idxinitialentry
                      {A}{IDX2}{}{277}
? 
./groff.toc:199: Emergency stop.
l.199 
      
./groff.toc:199:  ==> Fatal error occurred, no output PDF file produced!
Transcript written on groff.log.
/usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
make: *** [Makefile:14604: doc/groff.pdf] Error 1

It didn't even reach compilation. I'm afraid, to reproduce 1.23.0 build I have to restore corresponding environment from ALA. And no guarantee that some intermediate builds will not fail too.

dimich · 2026-03-08 16:57:31

seth wrote:

Why would one go for a "clean build" on bisection anyway?

Without re-bootstapping it fails immediately:

$ make
 cd . && /bin/sh /home/dimich/work/groff-debug/src/groff.git/build-aux/missing automake-1.18 --gnu
lib/gnulib.mk:2407: error: MOSTLYCLEANDIRS must be set with '=' before using '+='
Makefile.am:612:   'lib/gnulib.mk' included from here
make: *** [Makefile:7594: Makefile.in] Error 1

They use gnulib submodule, BTW. And it also has changed between 1.23.0 and 1.24.0.

seth · 2026-03-08 21:28:59

https://gitlab.archlinux.org/archlinux/ … type=heads - do you have the makedepends?
(Probably psutils?)

Without re-bootstapping it fails immediately:

Probably (only) the case when crossing Makefile.am and its includes changes.

dimich · 2026-03-09 12:32:19

seth wrote:

do you have the makedepends?

Sure, all makedepencies are installed.
First I succeeded to build 1.23.0 package with makepkg. It turned out that there are build artifacts listed in .gitignore which affect. "git clean -fd" doesn't remove them, "git status" shows no changes but build fails. After deleting whole repository directory and cloning it again 1.23.0 build succeeded. Removing directory is not a solution for bisect, I have to use "git clean -fdx".

However, it's not the end. At the very first bisect step compilation failed:

  CXX      src/roff/troff/div.o
In file included from src/roff/troff/div.cpp:29:
src/roff/troff/hvunits.h: In member function ‘units vunits::to_units()’:
src/roff/troff/hvunits.h:91:7: error: ‘ckd_mul’ was not declared in this scope
...

Probably something has changed in gcc, e.g. default standard or other option.

seth · 2026-03-09 15:20:14

ckd_mul is c23, they either started using that and fixed the compiler flags in a subsequent commit or accidentally used and reverted it
https://git-scm.com/docs/git-bisect#_av … g_a_commit - or force https://www.gnu.org/software/gcc/projec … s.html#c23

dimich · 2026-03-09 16:15:54

seth wrote:

ckd_mul is c23, they either started using that and fixed the compiler flags in a subsequent commit or accidentally used and reverted it

And since this is part of C but used in C++ code, it may be some changes in libstdc++ namespaces etc.
I'll take a look at nearby commits and/or try skip testing this problematic commit.

Meanwhile, it looks like regression is related to specific macro package(s). "groff -mandoc" is affected but "groff -me" is not.

wooptoo · 2026-03-09 22:17:12

Seeing the same issue;

time man PKGBUILD
----------------
Executed in  919.37 millis    fish           external
   usr time  412.04 millis    0.17 millis  411.87 millis
   sys time  518.09 millis    1.01 millis  517.08 millis

whereas before it was pretty much instant.

dimich · 2026-03-10 08:25:50

In C++ stdckdint.h appeared in C++26 standard, so I had to append "-std=gnu++26" to CXXFLAGS, and compilation succeeded. However, on next bisect step:

src/preproc/refer/ref.cpp: In function ‘int same_reference(const reference&, const reference&)’:
src/preproc/refer/ref.cpp:539:24: error: comparison between two arrays is not allowed in C++26 [-Warray-compare]
  539 |     if (r1.field_index != r2.field_index)

So yeah, automated bisect was a bad idea for this case

dimich · 2026-03-10 10:57:59

Well, it turned out that groff binaries don't matter. Content of macro directory matters (tmac/ in source tree or /usr/share/groff/current/tmac/ in packages).
Bisection shows that regression is introduced by this commit.

seth · 2026-03-10 16:18:18

https://savannah.gnu.org/bugs/index.php?65190
Certainly "motivated" but the price seems unreasonable - there's probably optimization potential.
Have you contacted GBR? (there's no bug about this)
For reference, https://savannah.gnu.org/bugs/index.php?67602 addresses a performance regression and continuous is probably the most common case.

dimich · 2026-03-11 11:36:35

seth wrote:

Have you contacted GBR? (there's no bug about this)

Should I contact him directly? I'm going to register at savannah.gnu.org and create a ticket. Currently I'm stuck little bit on how to properly describe the issue. For example, quadratic dependency of time on input size is observed with '-Tutf8' but not with '-Z'.

seth · 2026-03-11 15:11:07

NO, I was just asking because there was no bug nor a comment to the bug causing the patch.
-Z disables postprocessing so likely not a surprising behavior, more interesting might be whether -Tutf8 behaves different from -Tascii or -Thtml

dimich · 2026-03-11 18:16:23

seth wrote:

more interesting might be whether -Tutf8 behaves different from -Tascii or -Thtml

The same with 'ascii' and 'html' output devices.

Created upstream ticket: https://savannah.gnu.org/bugs/?68145

cryptearth · 2026-03-11 19:04:55

dimich wrote:

I understand that delay is not such a big problem and a matter of used to, but it's very annoying.

fun fact: half a second and someone curious to figure out why was how the xz attack was discovered

dimich · 2026-03-11 19:51:12

cryptearth wrote:

fun fact: half a second and someone curious to figure out why was how the xz attack was discovered

Yep, I also recalled that incident.

Arch Linux

#1 2026-03-08 05:56:20

Performance regression of man pages rendering after groff update

#2 2026-03-08 08:22:15

Re: Performance regression of man pages rendering after groff update

#3 2026-03-08 09:33:07

Re: Performance regression of man pages rendering after groff update

#4 2026-03-08 13:59:32

Re: Performance regression of man pages rendering after groff update

#5 2026-03-08 15:24:36

Re: Performance regression of man pages rendering after groff update

#6 2026-03-08 15:40:41

Re: Performance regression of man pages rendering after groff update

#7 2026-03-08 16:02:26

Re: Performance regression of man pages rendering after groff update

#8 2026-03-08 16:34:14

Re: Performance regression of man pages rendering after groff update

#9 2026-03-08 16:57:31

Re: Performance regression of man pages rendering after groff update

#10 2026-03-08 21:28:59

Re: Performance regression of man pages rendering after groff update

#11 2026-03-09 12:32:19

Re: Performance regression of man pages rendering after groff update

#12 2026-03-09 15:20:14

Re: Performance regression of man pages rendering after groff update

#13 2026-03-09 16:15:54

Re: Performance regression of man pages rendering after groff update

#14 2026-03-09 22:17:12

Re: Performance regression of man pages rendering after groff update

#15 2026-03-10 08:25:50

Re: Performance regression of man pages rendering after groff update

#16 2026-03-10 10:57:59

Re: Performance regression of man pages rendering after groff update

#17 2026-03-10 16:18:18

Re: Performance regression of man pages rendering after groff update

#18 2026-03-11 11:36:35

Re: Performance regression of man pages rendering after groff update

#19 2026-03-11 15:11:07

Re: Performance regression of man pages rendering after groff update

#20 2026-03-11 18:16:23

Re: Performance regression of man pages rendering after groff update

#21 2026-03-11 19:04:55

Re: Performance regression of man pages rendering after groff update

#22 2026-03-11 19:51:12

Re: Performance regression of man pages rendering after groff update

Board footer