Hi Tim, On Tue, Feb 26, 2019 at 06:16:12PM +0100, Tim Düsterhus wrote: > Willy, > > Am 13.02.19 um 17:57 schrieb Tim Duesterhus: > > *snip* > > Are you able to give some (first, basic) feedback on this patch already?
Not yet. In fact I don't know much what to think about it. The patch itself is reasonably small, but what's the real cost of using this ? We've created libslz because zlib was not practically usable due to its insane amount of memory per stream (256 kB), which resulted in compression being disabled for many streams by lack of memory, hence in a lower overall compression ratio. Here I have no idea how much brotli requires, but if it compresses each stream slightly better than zlib but at roughly similar (or worse) costs, maybe in the end it will not be beneficial either ? So if you have numbers (CPU cost, pinned memory per stream), it would be very useful. Once this is known, we can document such limits and let users decide on their own. We'll need the equivalent of maxzlibmem though (or better, we can reuse it to keep a single tunable and indicate it serves for any compression algo so that there isn't the issue of "what if two frontends use a different compression algo"). Thanks, Willy
