Re: don't gzip man files
The advantages of optionally doing man pages compression at package
install time include *all* the advantages of both not compressing at
all, and of always compressing at package build time, with the
additional advantages that it can be a local decision and requires
zero extra work by package builders. I urge you to consider this
solution seriously!
>> Reasons to gzip man files:
>> 1. save 6MB or so of disk space
>
> 2. Increase speed. (It does so on my system, and at least one
> other person has reported so in this forum).
I've got fairly inconclusive results on my DX2/66 at work:
muskogee:man1$ free
total used free shared buffers
Mem: 15160 14852 308 6168 4468
-/+ buffers: 10384 4776
Swap: 32756 9028 23728
muskogee:man1$ ls -l /hda1/richard/spong
-rw-r--r-- 1 richard richard 20971520 Apr 17 10:33 /hda1/richard/spong
muskogee:man1$ ls -l
total 186
-rw-r--r-- 1 root dstaff 138324 Apr 17 10:19 test_a.1
-rw-r--r-- 1 root dstaff 41745 Apr 17 10:19 test_a_z.1.gz
-rw-r--r-- 1 root dstaff 4226 Apr 17 10:34 test_b.1
-rw-r--r-- 1 root dstaff 1832 Apr 17 10:34 test_b_z.1.gz
muskogee:man1$ for i in test_a test_a_z test_b test_b_z; do cat /hda1/richard/spong >/dev/null; echo $i; time sh -c "man $i >/dev/null"; done
test_a
Reformatting test_a(1), please wait...
16.02user 2.08system 0:28.49elapsed 63%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (591major+1404minor)pagefaults 0swaps
test_a_z
Reformatting test_a_z(1), please wait...
16.57user 1.70system 0:25.51elapsed 71%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (589major+1675minor)pagefaults 0swaps
test_b
Reformatting test_b(1), please wait...
1.13user 1.01system 0:07.34elapsed 29%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (537major+1285minor)pagefaults 0swaps
test_b_z
Reformatting test_b_z(1), please wait...
1.05user 1.16system 0:08.35elapsed 26%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (598major+1511minor)pagefaults 0swaps
muskogee:man1$
These figures aren't very helpful - some things are faster and some
are slower, but IMHO none are sufficiently different to make a
decision either way based on speed. I imagine it would vary a lot
from machine to machine; which is why I think making it an option
would be best.
(test_[ab]_z is what you get by `gzip -9'ing test_[ab].)
I hope the methodology above is sane. I would imagine that faster
CPUs would show a more pronounced effect.
>> 2. disk space is very cheap
(it would be truer to say that disc being cheap means that disc space
is not a reason to compress man pages, rather than a positive reason
not to.)
> Really? I could use some. Murphy's law: there is no such
> thing as too much disk space. Also, on my machine, gzipping man pages
> also makes them faster. Really.
The 6Mb saving suggested above is about UKP1.20 at the price I bought
my current disc. I've encountered systems where even a few Mb might
be a worthwhile saving though.
>> 4. # find /usr/man -type f -name \*.[0-9]\* -print | xargs gzip -9
>
> Does that not make upgrades harder? If a man page is deleted
> from a package, how will dpkg know to delete blah.x.gz? I don't like
> files not belonging to any package on /, and /usr/ directories
> (Backing up /etc, /home, and /usr/local/ will allow me to recreate my
> system completely after a mishap), but this may be my personal
> idiosyncracy.
I've already suggested a possible solution to this one.
> Also, the user has to remember to manually gzip after every
> package update, know how to do it, and not make typos.
My solution takes care of this in a typo-immune manner. dpkg could
run the script automatically, if compressed man pages had been
selected.
>> 5. makes access of man pages via packages that don't support
>> compressed man pages impossible
>
> What packages? We went through all that we know exist on the
> Debian system at the moment. Also;
> % zcat /usr/man/man1/man.1.gz | nroff -Tascii -man | less
I think Daniel means we shouldn't cut out the possibility of using
other `man' packages. I don't know how serious a problem this would
be: it may be that all man page browsers can cope with gzip'd man
pages, or that those that can't aren't worth using for all sorts of
other reasons. (Does TkMan work with compressed man pages? I would
imagine so, but I don't have a copy to hand as it was too slow on my
old system.)
--
Richard Kettlewell
http://www.elmail.co.uk/staff/richard/ richard@elmail.co.uk
Reply to: