Follow-up Comment #16, bug #68145 (group groff): At 2026-03-17T13:15:51-0400, dimich wrote: > Follow-up Comment #14, bug #68145 (group groff): > > [comment #10 comment #10:] >> In other words, -M arguments prefix the usual search path for macro >> files. > > So as far as I understand, -M affects only how troff generates ditroff > and doesn't affect postprocessing (grotty has no -M parameter). Please > correct me if I'm wrong.
Correct. groff's output drivers don't interpret macros. > Hm, in section "Files" of grotty manual: > > /usr/share/groff/1.24.0/tmac/tty.tmac > defines macros for use with the ascii, latin1, and utf8 > output devices. It is automatically loaded by troffrc > when any of those output devices is selected. > > Is this path hardcoded at compile time for grotty? Yes, but it's handled as any other macro file, so it is influenced by the `-M` option and `GROFF_TMAC_PATH` environment variable; there's no special logic in GNU troff itself for this. Here's what gets it done: https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/troffrc?h=1.24.1#n24 Specifically, line 42 is what loads an output device's supporting macro file. > Although, grotty-1.24.0 processes ditroff generated by troff-1.24.0 > with 1.23.0/tmac as fast as grotty-1.23.0 processes ditroff generated > by troff-1.23.0 with 1.23.0/tmac. That's reassuring. :) > I'm trying to make sure that I measure right things to quantitatively > describe the qualitative "man pages started appear longer". I appreciate that. > Can also fonts directory affect somehow when output device is utf8 or > ascii? _Can_ it? Yes. I don't think it's relevant here, but since the "utf8" device supports many more glyphs than "ascii" or "latin1", there _is_ an effect. For example: $ wc -l build/font/devascii/R 190 build/font/devascii/R $ wc -l build/font/devutf8/R 1028 build/font/devutf8/R Since the "utf8" device's glyph list is 5 times longer (for each font), _grotty_ will experience greater startup overhead as it reads these files and populates data structures from them. But each font description file is read at most once each (per _grotty_ process lifetime). >> My hunch--and it is only that--is that if memory starvation produced >> a _quadratic_ degradation in performance, then we'd see a much more >> dramatic increase in memory pressure. > > Agree. > > I observe this behavior on two machines: laptop with 32 GB RAM and > desktop with 128 GB RAM. Both running Arch, no heavy load in > background, no fancy WM etc. > For the case, glibc 2.43+r5+g856c426a7534-1, kernel 6.19.8. > >> Can you re-run your test case using the -Z option so that _grotty_ >> is not involved at all? > > Already tested using -Z, no significant difference between 1.23.0 and > 1.24.0. The latter is slightly longer, just by few percent. Okay. That seems to leave _grotty_(1) as the only remaining variable. Deri blazed a promising trail in comment #14. I'm still intensely curious why different C++ language runtimes are reacting so differently to _grotty_'s demands for dynamic storage, even if the new approach to continuous rendering does make it thrash like a mosh pit. In my previous comment #15 I proposed some coping strategies _grotty_ might adopt if we can in fact attribute the performance hit to C++ runtime behavior, and the implementors thereof are unsympathetic to our usage pattern. So that I don't forget, I'll note that if we go with the "deliberate overallocation" technique, we might change `tty_printer::end_page()` to _realloc_(3) the `nlines` array back down to 66 lines. This might be advantageous for paginated input documents that employ multiple page lengths (admittedly a niche usage case), and I imagine it can't do any harm to continuous rendering: it will happen only once, since continuous rendering necessarily implies the existence of only one page. Presumably, _grotty_ will be exiting soon anyway--there's not much for it to do after the `end_page()` or the last (or only) page in a document. But it's polite and can sometimes be helpful to the system to free memory once it's no longer needed, instead of waiting for process death to free resources. (We've probably all met applications whose demands for memory seem suddenly to go _up_ when you tell them to shut down--"oh, you're wanting to write out some data to disk when you quit? I didn't have any buffers for that; let me grab some real quick"--and on a slow system they make things even slower.) _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68145> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
