[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