A few suggestions for bugzilla mail to gcc-bugs
Daniel Jacobowitz
drow@mvista.com
Mon Jun 2 22:03:00 GMT 2003
On Mon, Jun 02, 2003 at 05:50:03PM -0400, Daniel Berlin wrote:
>
>
> On Mon, 2 Jun 2003, Daniel Jacobowitz wrote:
>
> > On Mon, Jun 02, 2003 at 05:33:15PM -0400, Daniel Berlin wrote:
> > >
> > >
> > > On Mon, 2 Jun 2003, Andreas Schwab wrote:
> > >
> > > > Daniel Jacobowitz <drow@mvista.com> writes:
> > > >
> > > > |> Can you query the compressed size more quickly? We don't need to be
> > > > |> precise here...
> > > >
> > > > "gzip -l" should do the trick, provided that the input is seekable.
> > > This isn't shell script, it's perl, forking a new process in a very often
> > > used cgi script for every single attachment is *not* a good idea.
> > >
> > > But that's besides the point anyway.
> > > The data is *not* in gzip format in memory.
> > > It has no gzip header with the size in it in front.
> > >
> > > The *only* way to get the size is to decompress it.
> > > I could, of course, convert them all to be in-memory gzip files, but i'm a
> > > bit busy with other things at the moment to care about this.
> > > :)
> >
> > I still think we should have some way to get at the compressed size.
> > But I assume it's in the DB somewhere and databases were never my
> > strong point.
>
> Yes, that's trivial.
> But the compressed size is sometimes very far off, and it would trick
> people into thinking it was going to take 10x less size than it does.
>
> I picked a random C++ preprocessed file:
>
> 800k uncompressed,
> 89k compressed
>
> that's like 9:1.
Like I said, not shooting for accuracy here :) Anything that
compresses down to 5K, say.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
More information about the Gcc
mailing list