[PATCH] store --help messages in compressed form. saves 35k

Rob Landley rob at landley.net
Fri Apr 7 23:38:03 UTC 2006


On Wednesday 05 April 2006 5:29 am, Denis Vlasenko wrote:
> > >> Why don't you lzma (or bzip2) them?
> > >
> > >Indeed. bunzip2 code is even smaller than gunzip.
> > >(lzma is non-standard, may be unavailable on build box,
> > >so I hesitate to use it).
> >
> > Could we make this a CONFIG option? Something like
> > choice
> > 	prompt "compress usage messages"
> > 	default CONFIG_USAGE_NOCOMPRESSION
> > 	help
> > 	  text.
> >
> > config CONFIG_USAGE_NOCOMPRESSION
> > 	bool "Do not compress"
> > 	help
> > 	  Store usage strings in uncompressed format. This uses alot of
> > 	  space.
> >
> > config CONFIG_USAGE_COMPRESS_GZIP
> > 	bool "gzip"
> > 	depends on CONFIG_GUNZIP
> > etc, etc.
> > endchoice
>
> Yes, it's a "complete solution ofr all imaginable cases",
> but isn't that an overkill? There is a reasonable heuristic:
>
> 1) verbose --help is big - compress it if CONFIG_FEATURE_VERBOSE_USAGE,
>    else (non-verbose --help) do not compress it at all.
> 2) bunzip code is small (3k) - always use bzip for compression.

I thought it was about 6k, actually.  (My early test versions of the rewrite 
were 6.7k, and although I shrank it down from that, I didn't halve the size.)

> +000000be t get_bits
> +000000e7 t start_bunzip
> +000001c0 T uncompressStream
> +0000068f t get_next_block

Huh, 3k.  That's odd...

Where's read_bunzip()?

> > nor
> > available, or already have unlzma built-in, so it would be nice to be
> > able to cope with all these.
>
> Developer may lack lzma on build box, but we can be reasonably sure [s]he
> will have bzip2.

Busybox does not provide bzip2 compression software.  This means that my 
firmware linux build will no longer be able to build busybox under itself 
with this option enabled.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list