This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][LTO] Streamer re-org (what's left)
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 15 Aug 2014 10:14:38 +0200
- Subject: Re: [PATCH][LTO] Streamer re-org (what's left)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1408071337320 dot 20733 at zhemvz dot fhfr dot qr> <alpine dot LSU dot 2 dot 11 dot 1408071541180 dot 20733 at zhemvz dot fhfr dot qr> <alpine dot LSU dot 2 dot 11 dot 1408111049480 dot 20733 at zhemvz dot fhfr dot qr> <20140814163337 dot GA27831 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1408150938570 dot 20733 at zhemvz dot fhfr dot qr>
> > patched:
> > real 6m12.437s
> > user 51m18.829s
> > sys 4m30.809s
> >
> > WPA is 129s, stream in 29.23s, stream out 12.16s.
> >
> > Patched + fast compression
> > real 6m4.383s
> > user 49m15.123s
> > sys 4m31.166s
> >
> > WPA is 124s, stream in 29.39, stream out 7.33s.
> >
> > So I guess the difference is close to noise factor now. I am sure there
> > are better compression backends than zlib for this purpose but it seems
> > to work well enough.
>
> Yeah, we might want to pursue that lz4 thing at some point.
>
> I'll take the above as an ok to go forward with this change
> (moving compression to the "stream" level from section level).
Yep, I would go with fast compression for wpa->ltrans objects. Those are going
to be consumed just once and the compression level increase is probably not
terrible (i.e. not as bad as current growth caused by not compressing strings
:)
3-fold decrease in /tmp usage is nice, but it +-10% does not matter much. BTW
if I remember well, zlib algorithm works on 64Kb blocks independently, so
perhaps havin 2MB buffer is unnecessarily large.
Honza
>
> Richard.