This Time Self-Hosted
dark mode light mode Search

A word against ecompress

No, I’m not going to criticise the ecompress implementation, actually I’m quite glad that ecompress was created, because it’s that, which allows what I’m going to write here 😉

So, on most modern systems, with the exception of servers and laptops, one of the problems you most rarely have is running out of disk space. Standard 3.5” SATA drives are cheap and so rarely you have to save disk space. So while I think it’s still a good default to compress manpages, info pages and documentation, most users don’t really need that.

So if you don’t mind using some more space for documentation and man pages, you might want to try this on your make.conf:

PORTAGE_COMPRESS=""

This way ecompress will be a no-op and will skip on compressing the doc, installing it non-comrpessed, using more space, but less (not much less, but still less) CPU time during build.

One nice advantage is that also displaying manpages will be faster as it doesn’t have to decompress them on the fly 😉 (and bzip2 can be quite slow to decompress even on modern computers, when compared to gzip).

Comments 10
  1. I am not sold to this ‘turn compression off’ idea.First of all, while hdd space is a lot cheaper then some years ago, hdds still fill up freakishly fast. Movies, music, games all need tons of space.The second reason, I use a tape lib for backup – and while it does have hardware compression, this feature can not be used, because you never know when the tape will be full – and the backup fails. Will it write 40gb? 50? 65? It is much more safer to have the hardware compression off and compress the stuff on disk. That way I can write 35’gb’ compressed data onto one tape without fearing failure (it is a 35/70gb dlt). Have mbuffer switch tapes every 32 ‘real gb’ and all backups are successfull.

  2. I just wish it didn’t compress EVERYTHING you install with dodoc like PDFs. You end up having to install it the long way round.

  3. Seems like our last commenter didn’t even read my blog at all, as usual someone has to write without thinking. I said the default is good to have it enabled, but in most cases on modern desktops, the compression can just be disabled without problems.Consider that on my system, which is quite loaded with stuff, the documentation and manpages take about 160MB compressed… even if the compression was worth 30%, it wouldn’t go over 1GB, which is quite less than my own music library.For what concern backups, I find it an overkill to backup /usr/share/doc and /usr/share/man in the first place.But once again, it’s not a common usage pattern to have a tape backup of everything.

  4. Seems that other distributions (like Mandriva) defaults to lzma for compressing man pages. I will have to try it if I have a bit of free time :-/

  5. ok, complete backups are not valid?How about this: no matter how fast your harddisk is, the cpu is always faster. And CPUs are turning up their performance a lot faster than harddisks.So the time lost to decompression matters less and less every couple of month.

  6. It’s opinable if complete backups are useful or not; I find a 100% backup not really that useful, when you can spare stuff like documentation, which you can easily regenerate. But that’s up to anybody.And I actually have a rather old CPU, but I have no intention to change CPU (and motherboard and memory) every couple of months… the disks instead I often end up changing about once an year for one reason or another.And, usually I have more CPU in use than disk, so certainly opening a man page takes less time if it’s not compressed. So as I don’t see using up 200MB more on disk, compared to waste less CPU as a bad exchange, I’d rather disable ecompress.

  7. I noticed the same thing few months back. After doing PORTAGE_COMPRESS=””, I no longer need to use some stupid bzcat or alike to read documentation, which I generally prefer to (a) have and (b) to have in easily accessible form.

  8. The thing that pisses me off about ecompress is that it’s done “automatically” after src_install is finished, and isn’t very good about putting stuff anywhere but ${D} even when by normal rules it’s supposed to.

Leave a Reply to FlameeyesCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.