Hi Werner,
Werner LEMBERG wrote on Sun, Nov 05, 2017 at 06:38:14PM +0100:
> Ingo Schwarze wrote:
>> In that sense, macro file size does seem to be the main effect, and
>> the savings in execution time seem to usually fall into the range of
>> 5-20% in cases that occur in practice.
> OK, but groff is not man pages only -
That is very true, but strip.sed is only used for -mdoc, -me, -mom,
and hdtbl.
> essentially, man pages never use extensive loops...
Which implies that it isn't very relevant for the use case involving
more than half of the files affected (6 out of 10)?
Regarding -me:
$ wc tmac/e.tmac-u
2068 6874 34265 tmac/e.tmac-u
$ wc build/tmac/e.tmac
1759 4270 22078 build/tmac/e.tmac
Did anybody ever evaluate the importance of those 300 bytes?
Are -me and -mom documents notorious for using large macros inside
deep loops? In particular as opposed to -ms and -mm, which are
installed unstripped?
$ wc contrib/mm/m.tmac
3577 11892 78966 contrib/mm/m.tmac
$ wc tmac/s.tmac
1980 5957 37779 tmac/s.tmac
>> a) You mean that savings of 5-20% in execution time are
>> "significant", even though formatting with mandoc would save
>> about 60-90% of formatting time instead?
> Ralph has answered this :-)
I didn't mean people ought to switch to mandoc. I meant i rarely
consider 5-20% execution time savings "significant" in any context,
and even less so for a program that is not optimized for speed by
its basic architecture in the first place (as demonstrated by the
comparison to mandoc). Note that the mandoc architecture isn't
optimized for speed either, but for simplicity...
>> b) Or do you mean that for a contrived test file calling mdoc(7)
>> macros many times in a .while loop, with little or no text in
>> the input file except that tight loop, savings are likely much
>> larger? AFAIK that was never tested, but how would it be
>> relevant?
> Again, groff is more than just using the man and mdoc packages.
> The stripping off of comments is part of groff's build process
> since 30 years or so - I don't see an immediate reason to change
> that. Bjarni's suggestions of better documentation is the way
> to go IMHO.
I can certainly live with that, it's only a minor inconvenience.
I was simply interested in understanding the rationale.
Yours,
Ingo
