Re: Compressed man pages (was: Accessibility of man pages (was: Playground pager lsp(1)))

Colin Watson
2023-04-09T12:29:24Z

On Sun, Apr 09, 2023 at 02:05:08PM +0200, Alejandro Colomar wrote:
> Important note: Sam, are you sure you want your pages compressed
> with bz2? Have you seen the 10 seconds it takes man-db's man(1) to
> find a word in the pages? I suggest that at least you try to
> reproduce these tests in your machine, and see if it's just me or
> man-db's man(1) is pretty bad at non-gz pages.

man-db is significantly slower with bzip2 than gzip these days, because
much of the performance work I did in 2.10.0 only applies to gzip:
there's in-process support for decompressing gzip, but we use
subprocesses for bzip2. IMO the relatively small difference in
compressed size doesn't justify the effort of building in-process
support for multiple compression algorithms. I recommend that
distributions just use gzip; but if distributions _really_ want to use
something else for whatever reason, then perhaps they should contribute
code to man-db to ensure similar performance to gzip. I'm happy to give
pointers if there's a sufficiently compelling reason to make it worth
the effort.

> - man-db's man(1) is slower with plain man(7) source than with .gz
> pages for some misterious reason.

Maybe CPU is sufficiently cheaper than I/O that the fact of reading less
data from disk dominates.

(Can I request that any concrete actions that need to be taken based on
this thread be split out to separate bug reports or something, please?
This thread is long and I don't really want to have lots of meandering
discourse in my inbox going back over the tired old man vs. info debate
or whatever, but if there are actual things I need to fix in man-db then
I'd rather not miss them.)

--
Colin Watson (he/him) [cjwatson@debian.org]