[BusyBox] Patch: libbb/unzip.c size reduction

Manuel Novoa III mjn3 at busybox.net
Mon Dec 3 10:01:30 UTC 2001


Glenn,

On Sat, Dec 01, 2001 at 08:52:11PM +1100, Glenn McGrath wrote:
> On Sat, 1 Dec 2001 01:36:26 -0800
> "Aaron Lehmann" <aaronl at vitelus.com> wrote:
> 
> > P.S. busybox gzip seems to be 2/3 as fast as /bin/gzip. I think this
> > is probably acceptable, and doubt it it due to any of my changes.
> > Still, it may be worth looking into at some point.
> > 
> 
> This came about with some changes i made a while back, previously unzip
> used low level file descriptors and had its own internal byte buffer,
> streams are supposed to be buffered so i replaced the low level file
> descriptors and buffering code with streams to save space.
> The amount of buffering in streams can be set, but in hindsight mustnt
> be as fast.

In this case I doubt that buffering is the cause of any slowdown.  What will
cause a significant slowdown though is having to call function fgetc for
each byte.

Traditionally, stdio would provide a macro version of getc to avoid the
overhead of the function call while there was data buffered (at the cost
of some extra code generated).  However, since such an approach isn't
thread-safe, glibc now defines getc as a function call.  As uClibc doesn't
(currently) do threads, it still uses the traditional approach.

If you're using glibc, you can still access traditional getc behavior by
using the macro _IO_getc_unlocked defined in libio.h and included by stdio.h.

Manuel





More information about the busybox mailing list