Update of bug #68145 (group groff):
Status: Need Info => Confirmed
Assigned to: None => gbranden
_______________________________________________________
Follow-up Comment #18:
The smell that Deri detected in comment #13 is steadily getting a stronger
gunpowder aroma.
$ time m=$(man -w bash) && for n in $(seq 64); do cat "$m" >> 64bashes.man;
done
real 0m0.084s
user 0m0.036s
sys 0m0.045s
$ groff --version | head -n 1
GNU groff version 1.24.1
$ time groff -m an -T utf8 -Z 64bashes.man > 64bashes.grout
real 0m12.372s
user 0m12.213s
sys 0m0.152s
$ ls -hl 64bashes.*
-rw-r--r-- 1 branden branden 55M Mar 17 17:52 64bashes.grout
-rw-r--r-- 1 branden branden 24M Mar 17 18:12 64bashes.man
$ time ~/groff-1.23.0/bin/grotty 64bashes.grout >/dev/null
real 1m30.758s
user 0m31.980s
sys 0m58.758s
$ time ~/groff-1.24.0/bin/grotty 64bashes.grout >/dev/null
real 1m36.857s
user 0m35.132s
sys 1m1.659s
Observations:
1. Constructing the input takes almost no time at all--24 megs of man page in
under a hundredth of a second.
2. For such prodigious input, the formatter itself isn't taking a crazily long
time.
$ time groff -rC1 -rcR=0 -m an -T utf8 -Z 64bashes.man >|
64bashes-paginated.grout
real 0m12.815s
user 0m12.604s
sys 0m0.198s
$ grep '^p' 64bashes-paginated.grout | tail -n 1
p8960
Almost 9,000 pages in about 13 seconds. Not great, not terrible.
3. Observe that _groff_ (since no preprocessor is required or asked for, and
`-Z` is given, this is pretty much all _troff_ itself), spends only a little
over 1% of its time in the kernel.
4. But check out _grotty_. It takes about 7½ times as long to run as the
formatter itself, and spends **two-thirds** of its time in the kernel. This
is a red flag with a spotlight on it erected in the path of gas turbine
exhaust to make it flutter. And as every aero major knows, you always run a
gas turbine wide open whenever you can because that's its most fuel-efficient
configuration. (This is why we should have ground tugs handling all airframe
propulsion on taxiways...but I digress.)
5. _grotty_'s performance is not substantially different when comparing
1.23.0 and 1.24.0. This too makes sense, because nothing about its dynamic
memory management materially changed in the previous development cycle. My
new approach to continuous rendering appears to have blundered straight into
an ancient tar pit.
Conclusion: now that I can reproduce the performance hit, I have something I
can work with.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68145>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
