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@xxxxxxxxxx]
