Follow-up Comment #10, bug #68145 (group groff): [comment #8 comment #8:] > [comment #7 comment #7:] >> I still can't reproduce this. > > This is strange. > > Slightly different measurement method: measured execution time of grotty > processing ditroffs generated using different versions of macro-directories.
> #!/bin/bash -e
>
> for ((n=1; n<=64; n*=2)); do
>
> for v in 23 24; do
> for ((i=1; i<=$n; i++)); do
> cat bash.1
> done | troff -M groff-1.$v.0/tmac/ -man -Tutf8 > bash_troff-1.$v.0.ditroff
> done
>
> for v in 23 24; do
> declare "dur$v"=$(/usr/bin/time -f "%U" grotty < bash_troff-1.$v.0.ditroff
> 2>&1 > /dev/null)
> done
>
> printf "% 3s\t% 4s\t% 4s\n" $n $dur23 $dur24
> done
> gives
> 1 0.12 0.12
> 2 0.23 0.28
> 4 0.47 0.62
> 8 0.94 1.59
> 16 1.87 4.56
> 32 3.75 14.31
> 64 7.49 63.89
I see the supra-linear growth of the figures in the right-hand column, but
cannot yet account for it.
> Maybe measurement method is wrong, or some quirks of my system. However,
> increase of man pages rendering time noticed not only by me.
As noted in comment #9, I'm attempting to recruit help. Once I can get the
problem to manifest on my system, I'm reasonably confident that I can
root-cause it.
> Do I understand correctly that -M option overrides default search paths, not
> appends specified one to default?
troff(1):
...
Options
...
-M dir Search directory dir for macro files. See the description
of GROFF_TMAC_PATH in section “Environment” below for the
default search locations and ordering.
Environment
GROFF_FONT_PATH and GROFF_TMAC_PATH each accept a search path of
directories; that is, a list of directory names separated by the
system’s path component separator character. On Unix systems, this
character is a colon (:); on Windows systems, it is a semicolon
(;).
...
GROFF_TMAC_PATH
A list of directories in which to search for macro files.
troff will scan directories given as arguments to any
specified -M options before these, then the current
directory (only if in unsafe mode), the user’s home
directory, a site‐specific directory (/home/branden/
groff-1.24.1/share/groff/site-tmac), and a standard location
(/home/branden/groff-1.24.1/share/groff/1.24.1/tmac) after
them.
(My local build is installed into my home directory, so the paths reported by
your copy of the man page will differ, and correspond to your installation.)
In other words, -M arguments prefix the usual search path for macro files.
> Should I attach ditroffs generated in both cases on my side?
Not necessary. They'll be huge and I suspect, at this time, that they won't
tell us anything interesting.
No one's reporting **incorrect** output. Just un-performant output.
> Just noticed that output from grotty processing 1.23.0 ditroff appears in
> terminal immediately while processing. But grotty processing 1.24.0 is quiet,
> and output appears only at the very end.
That's expected. It arises from the switch of the _man_ package's
implementation of "continuous rendering" from the previous method to one
employing an interim huge page length (the maximum possible page length, in
fact), then, when input is exhausted, reconfiguring the page length to be
wherever the vertical drawing position actually is.
That is what the commit your bisection exposed implemented.
_grotty_ formats and writes its output one "page" at a time. In _groff_
1.23.0 and earlier going back many years (but not "all the way"), what you got
in practice from _grotty_ were pages of varying and inconsistent length. This
caused problems for the _tbl_ preprocessor (like bug #67420), which is why I
made the aforementioned change to the continuous rendering implementation.
Theoretically, _grotty_ could be managing memory badly as a consequence of
this change, because it's managing a lot _more_ of it as the size of a "page"
grows to huge proportions, but I should be able to reproduce that with my
_bash_ experiment. I can't.
> Valgrind also shows difference in allocated memory (single bash.1 copy used
> as input):
> $ valgrind grotty < ./bash_troff-1.23.0.ditroff > /dev/null
> ...
> ==11110== HEAP SUMMARY:
> ==11110== in use at exit: 24,957 bytes in 1,754 blocks
> ==11110== total heap usage: 619,653 allocs, 617,899 frees, 97,048,485 bytes
> allocated
>
>
> $ valgrind grotty < ./bash_troff-1.24.0.ditroff > /dev/null
> ...
> ==11151== HEAP SUMMARY:
> ==11151== in use at exit: 24,957 bytes in 1,754 blocks
> ==11151== total heap usage: 618,293 allocs, 616,539 frees, 195,303,380
> bytes allocated
That's consistent with the foregoing. I note with some interest that the
total number of allocations and frees is nearly constant, and while the
overall allocation grew (as we'd expect given the new page length strategy),
it only doubled. My hunch--and it is only that--is that if memory starvation
(or even just thrashing, if the libc aggressively released heap storage back
to the OS kernel and then demanded it again, trapping into the kernel with
great frequency) produced a _quadratic_ degradation in performance, then we'd
see a much more dramatic increase in memory pressure.
195 megabytes was an unimaginable amount of memory when I was a kid, but it's
not much today--not on any machine that runs Firefox or Chrome. According to
my current Firefox session, a browser tab that I have open to Amazon is eating
a gigabyte--and it stays open much longer than the time required by even the
worst of the input cases observed in this ticket (30-60 seconds).
Can you re-run your test case using the -Z option so that _grotty_ is not
involved at all?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68145>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
