Re: [groff] [patch] do not strip mdoc macros

[Ingo Schwarze]

Hi Ralph,

Ralph Corderoy wrote on Mon, Mar 18, 2019 at 01:58:56PM +0000:
> Ingo Schwarze wrote:

>> Given that i only sent a patch to stop stripping mdoc(7) in order to
>> keep the discussion focussed on one macro set at a time, i'm only
>> testing mdoc(7) for now.

> I'm happy for a decision to be made on mdoc alone, but the issue is
> perennial and so it might be nice to decide a consistent policy for all,

We tried that in the past, but the discussion had a tendency to not
reach a clear conclusion because it kept jumping from one macro set
to another without reaching a definite result for any of them.

In contrast to that, inspecting one macro set at a time has proven
more effective.  That way, a few macro sets were already identified
where we reached consensus that stripping provided no significant
benefit for them, and so stripping was removed from these sets.

Consequently, making a decision on mdoc(7) may also help the general
case:  if we come to the conclusion that stripping isn't needed for
mdoc(7), the remaining set of stripped macro files is reduced, making
it simpler to subsequently consider the general case.

[...]
>> One among the largest and most complicate mdoc(7) pages i'm aware of
>> is the ksh(1) manual:

> And mdoc might be a simple macro set compared to some.

Even though it does contain loops for argument parsing, that may
well be true; plus manual pages tend to be short, and fancy programming
is discouraged in their source code, all of which means stripping
may be of little relevance for mdoc(7).

>>    $ wc ksh.1
>>   5600   25263  134843 ksh.1
>>
>>    $ time troff -mdoc -Tps ksh.1 > /dev/null      

> (I saved the output so it could be cmp(1)'d.)

>> Average: 0.735 +- 0.008

> I have mksh.1 to hand here, MirBSD's fork of ksh.
> 
>     $ wc mksh.1
>       6906  32281 175249 mksh.1
> 
> perf(1) says
> 
>     2,163,307,701 instructions:u                                              
>       2.184278895 seconds time elapsed
> 
> so you've a faster CPU than me.  :-)

Heh.  :-)

If it takes three times longer for you, then chances are the
difference is also about three times larger for you.  Given that
the difference was about 30ms for me, extrapolating would suggest
it might be around 100ms for you.

Which only confirms the argument that the difference appears
to be very small even for large mdoc(7) documents.

Yours,
  Ingo