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
