> As a reality cross-check: How long does the slowest system available
> take to render the largest manual page in the base installation? If
> that's less than 5 seconds, I'd say the warning can be omitted.
I did a few quick tests on my SPARCstation-20 (hardly the slowest
sparc, and sparc is hardly the slowest port). My SS20 is running my
mutant 1.4T, but still may be indicative; while I have nothing but
vague feel to back it up, my impression is that tools like nroff slow
down with more recent versions.
Teal deer: don't skip the warning. (But maybe don't print it unless
nroff is taking longer than 5 seconds?)
The largest file in /usr/share/man/man* on that SS20 is ksh.1, which is
140179 octets. But size is not the whole story; complexity matters
too. Here are some data points. All runs are done on that same SS20,
whose CPU is "RT620/625 @ 125 MHz". All time figures are ±1s, because
they're based on a shell loop
for f in ...
do
ls -l $f
date
nroff -mandoc < $f > /dev/null
date
done
and then (manually) subtracting the before timestamp from the after
timestamp and editing the result into this list.
Source Bytes nroff time
/usr/share/man/man1/ksh.1 140179 4s
/usr/share/man/man1/gcc.1 109360 4s
/usr/share/man/man1/lex.1 104862 3s
/usr/share/man/man7/mdoc.samples.7 69334 19s
/local/src/moussh/moussh/moussh.1 134421 26s
I included the moussh manpage - not, of course, in base - because it's
a fairly complex one. Compared with the ksh page, it's a good example
of how complexity affects time significantly even for approximately the
same size. (I'll be happy to send a copy of moussh.1 to anyone who
wants one, or you can git clone git://git.rodents-montreal.org/moussh
and get it from there - the one I used is from commit 4c6d154.)
I did more nroff -mandoc runs before the above, so they were all done
with approximately the same warm filesystem cache.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML [email protected]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
