Re: man page rendering speed

[Ingo Schwarze <schwarze@usta.de>]

Hi Eli,

Eli Zaretskii wrote on Fri, Apr 07, 2023 at 06:06:39PM +0300:
> G. Branden Robinson wrote on Date: Fri, 7 Apr 2023 09:43:19 -0500

>> ...which brings me to the other factor, of which I'm more confident: man
>> page rendering times are much lower than they were in Unix's early days.
>> 
>> On my system, all groff man pages but one render in between a tenth and
>> a fortieth of a second.  The really huge pages like groff(7),
>> groff_char(7), and groff_diff(7) are toward the upper end of this range,
>> because they are long, at ~20-25 U.S. letter pages when formatted for
>> PostScript or PDF, or have many large tables so the tbl(1) preprocessor
>> produces a lot of output.
>> 
>> The outlier is groff_mdoc(7) at just over one-third of a second.

> Some people consider 0.1 sec, let alone 0.3 sec, to be long enough to
> be annoying.
> 
> Also, did you try with libpng.3 or gcc.1?

For what it's worth, on my notebook the largest page is ffmpeg-all(1)
at about 1.6 Megabyte man(1) source code, 42k lines, 182k words,
1.65 Megabyte rendered to UTF-8 terminal output.

Rendering that beast takes three and a half seconds on my notebook
with groff and two thirds of a second with mandoc(1), i.e. mandoc
is more than five times faster on this page than groff.

The largest mdoc(7) page here happens to be openssl(1) at 193 Kilobyte
of mdoc(7) source code, 5k lines, 27k words, 265 Kilobyte of UTF-8
terminal output in rendered form.  It takes 1.3 seconds with groff and
on tenth of a second with mandoc, so mandoc is faster by a factor of
thirteen in this case.  In general, the speed gain of mandoc is much
larger for mdoc(7) than for man(7) input because mandoc refrains from
using recursion in the implementation of the mdoc(7) language.

Relative speed gains also tend to be larger for large pages than for
small ones, so these factors of five and thirteen are on the upper
end of the spectrum.  Then again, who cares about rendering speeds
for small pages, apart from Michael Stapelberg when he pre-renders
stuff he is planning to serve on manpages.debian.org?

In fact, speed was among the design goals of mandoc when development
started about 15 years ago (though the goal was secondary to the goals
of BSD licensing, ease of use, and security, and in the meantime,
the goal of high-quality HTML output has also become more important).

Consequently, people who highly value speed in manual page display
might consider mandoc as an option for a manual page searching,
formatting and display system.  Several Linux distributions nowadays
offer the configuration option of using it out of the box (including
Fedora, openSUSE and Arch), and some even use it by default (including
Alpine, Void, illumos and, of course, almost all BSD systems).

Of course, it is *not* a replacement for groff.  Mandoc only provides
rather poor PDF output and it can only format manual pages, not
general-purpose roff(7) documents.

Yours,
  Ingo