Re: man page rendering speed (was: Playground pager lsp(1))

[Colin Watson <cjwatson@debian.org>]

On Fri, Apr 07, 2023 at 09:43:19AM -0500, G. Branden Robinson wrote:
> At 2023-04-07T09:36:10+0300, Eli Zaretskii wrote:
> > > From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> [re-running *roff when a viewing a man page and resizing the terminal]
> > > Seems like it shouldn't be impossible to me, but what I imagine
> > > would require a little reëngineering of man(1), perhaps to spawn a
> > > little custom program to manage zcat/nroff pipeline it constructs.
> > > This little program's sole job could be to be aware of this pipeline
> > > and listen for SIGWINCH; if it happens, kill the rest of the
> > > pipeline and reëxecute it.

I didn't see the rest of the thread, but one significant complexity here
would be interacting with the pager to arrange for the viewing position
to be returned to where it was pre-SIGWINCH; bear in mind that the pager
is user-configurable (less(1) is common but not universal) and isn't
directly part of man(1).

> > This should be possible, but it flies in the face of the feature
> > whereby formatted man pages are kept for future perusal, which is
> > therefore faster:
> 
> You're referring to cat pages.  As far as I know, these are on their way
> out if not already gone.  Colin Watson, who has maintained the man-db
> implementation of man(1)[1] for something like 20 years, can speak more
> authoritatively to this, but as I understand it, the advent of resizable
> xterm windows started to kill the utility of cat pages decades ago and
> the increasing importance of desktop environments accelerated their
> demise.

Another major change in that period was the general though gradual move
to UTF-8, making it somewhat unclear for some time which encoding should
be preferred when rendering cat pages.  (Since 2010, man-db always saves
cat pages in UTF-8 and converts to the proper encoding at display time,
but it took a while to settle on this approach and in the meantime there
were perhaps four or five years when cat pages were commonly unavailable
in practice.  Even then, very few people cared enough to complain.)

Furthermore, the traditional approach to saving system-wide cat pages
involved having man(1) be set-id.  From a modern standpoint, this was
obviously problematic, and it caused both security vulnerabilities and
more ordinary bugs.  There are ways in which this might have been
rearranged to be less of a serious problem, but if you can avoid
bothering with set-id at all then that's clearly safer.

My general approach to cat pages for at least the last ten years has
been to put as little effort into them as possible.  This has so far
included not outright removing support for them (since dealing with the
resulting support load, even if small, would itself be effort), but if
an improvement to man(1) has some kind of degradation of cat pages as a
side-effect then I usually won't hesitate to make it anyway.

> ...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.

Indeed, and it's been the case for at least a decade that rendering
times have been short enough that they can largely be considered
negligible.  (For most of that time my own equipment has not been
particularly on the bleeding edge of performance.)

> The bottom line is that, even on BSD systems (where mdoc(7) is preferred
> to man(7)), a user can expect a man page to render from *roff source in
> less than, say, half a second in the worst case, and the median
> GNU/Linux user can expect to start reading a man page "instantaneously":

The other thing to note explicitly here is that what normally matters
most is the time to _start_ reading, not the time to render the whole
page.  My usual example for where this makes a difference is zshall(1),
which is a concatenation of several other pages and comes to about 30000
lines of 80-column rendered output; on my system this takes about 0.6
seconds to render in its entirety, but typing "man zshall" nevertheless
shows the first page subjectively instantaneously.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]