Update of bug #68326 (group groff):
Item Group: Rendering/Cosmetics => Refactoring
Status: None => Need Info
Summary: grotty buffers entire output into memory for
unpaginated documents => [grotty] buffers entire output into memory for
unpaginated documents
_______________________________________________________
Follow-up Comment #4:
I have several objections to this patch.
[comment #0 original submission:]
> While the resolution to https://savannah.gnu.org/bugs/?68145 fixed end-to-end
> render times, I am still observing a regression over groff 1.23 on the metric
> of time-to-first-byte, i.e. how long you have to wait when issuing a man
> command on a very long document before your pager starts rendering anything.
What is this "very long document"? Is it a practical one? Is it a man page
that is part of any well-known software project or GNU/Linux distribution? I
see below that the input file is named "~/configuration.nix.5". Is that
something all NixOS systems produce? How big _is_ it? Why is it as large as
it is?
> I determined that the root cause of this is the same as #68145, that
> following the changes to the man macros, grotty is now buffering the entire
> document into memory before displaying anything.
Yes, that's because the entire page has to be addressable. Otherwise you get
bugs like the one that compelled me to refactor the _man_ package's handling
of continuous rendering in the first place. See bug #65189 and bug #65190.
Also, review the context within which _grotty_ works. It is an interpreter of
_troff_ command output. That has several implications.
https://www.gnu.org/software/groff/manual/groff.html.node/Output-Structure.html
"Semantically, the body is page-oriented. The p command starts a new page.
Positioning, writing, and drawing commands are performed within a page, so
they cannot occur before the first p command."
> While there is no longer any allocation thrashing, this is still too long to
> wait for a man command.
Two and a half seconds is a noticeable interval, that's true. If you're using
man-db _man_(1), set `MANROFFOPT=-Z`. That takes _grotty_ out of the
pipeline. Are you still waiting too long for the _man_ command? If so, your
patch does not sufffice to solve the problem.
> I've attached a patch to periodically flush the head of the grotty line
> buffer. I verified it produces byte-identical output on my pathologically
> large manpage as well as continuing to pass all tests.
You haven't shared the document by which you reproduced this poor performance,
but I suggest you construct a man page such that most of the body text is a
_tbl_(1) table using the "allbox" region option. More precisely, any table
with a vertical rule in it should do, just make sure it takes up almost the
entire document.
Then tell me if the output is byte-identical to _groff_ 1.24.1 or Git HEAD.
> For the command: time ./result/bin/troff -Tascii -Wall -man
> ~/configuration.nix.5 | ./result/bin/grotty | head >/dev/null
As noted above, you're timing the whole pipeline here. That's a reasonable
proxy for running _man_, but for the scenario I have proposed, you'll need
_tbl_ in the pipeline as well (at the start, because it's a preprocessor).
Also, what is the application, for the practical human man page reader, of
closing the pipe after the first ten lines and sending the output to
/dev/null? Why would someone render a man page at all if they dispose of it
that way?
I think this bug report reflects tunnel vision about performance tuning (at
which point the classical question is, "have you tried Gentoo?") and
disregards the practical utility not just of man pages, but of _grotty_ input
in general, which is not limited to man pages, but any sort of document GNU
_troff_ can produce.
> 1.23.0:
> real 0m0.013s
> user 0m0.010s
> sys 0m0.012s
>
> 1.24.1:
> real 0m53.468s
> user 0m14.779s
> sys 0m41.223s
>
> master:
> real 0m2.545s
> user 0m3.077s
> sys 0m0.171s
>
> master + attached patch:
> real 0m0.110s
> user 0m0.130s
> sys 0m0.017s
Please follow-up with your best effort at convincing counter-arguments. I
look forward to reading them.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68326>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
