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