[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] [Groff] Unintended impact of strip.sed on om.tmac-u?

From: Peter Schaffter
Subject: Re: [groff] [Groff] Unintended impact of strip.sed on om.tmac-u?
Date: Mon, 13 Nov 2017 11:10:04 -0500
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Nov 13, 2017, Doug McIlroy wrote:
> It has been said that stripping tmac files improves their 
> perfomance. I tried it on s.tmac. It cuts the file by 48%.
> But on a real-life groff file of considerable complexity
> it saved less than 1% of cpu time.
> This example suggests that stripping may be a frill that
> makes groff maintenance more complicated to little advantage.
> Does it make more difference in other macro packages?
> If so, a comparison of commenting styles might reveal 
> style recommendations that would overcome the need for
> stripping. 
> In short, I wonder whether stripping is an instance of
> gnu bloat, a disease that groff has generally aavoided.

I'm in two minds about this.  I'm all for speed and efficiency and a
lean, mean installation, but...

As concerns 'while' loops and extensive comments, mom is the worst
offender--if that's the word--so stripping would seem to make sense.
On the other hand, the while loops (all 122 of them!) simplify
the assignment of registers and strings so the code is easier to
read, and the comments and strict indentation are specifically to
help users mucking around in om.tmac.  It's sort of contrary to
the spirit of the mom macros (i.e. make groff more approchable) to
render om.tmac impenetrable by stripping.

Back when I was first working on mom on a 386, I noticed that
'while' loops slowed things down.  In the past decade or so, on
contemporary machines, I have not been aware of it.  My user
experience of mom, as opposed to precise benchmarking, shows no
appreciable difference in the speed of processing mom files whether
om.tmac is stripped or not.

I have, admittedly, never processed a document larger than a 600
page novel.

Peter Schaffter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]