> > 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.
