Wanted: A crate that implements a buffered zlib decoder that buffers, say, 32K of uncompressed data by doing the decompression in a separate thread. I think it’d be an easy way to speed up a lot of apps (image decoding, etc.) via pipelining, without much effort.
-
-
Replying to @pcwalton
I've tried this with zlib on text and weirdly, the thread communication cost more than it saved. (ymmv, this was a long time ago, maybe it wasn't as efficient comm. as it could have been, etc.)
1 reply 0 retweets 0 likes -
Replying to @davidcrawshaw
I did it for PNG decoding and it was a massive speedup. In fact it was basically optimal—the entire thing got bottlenecked on zlib. The trick is that you have to have something for the main thread to pipeline with—in PNG’s case, that’s the prediction/filtering.
1 reply 0 retweets 1 like -
Replying to @pcwalton
Yeah maybe my problem was not doing anything computationally heavy with the text once I had it.
1 reply 0 retweets 0 likes -
Replying to @davidcrawshaw
I suspect the same trick will work for JPEG, although in the case of JPEG I’d rather just offload the iDCT to the GPU.
1 reply 0 retweets 1 like -
Replying to @pcwalton
Nasty memory bandwidth / latency problems to think about with tiny jpegs. But there's probably an optimal subset to offload (esp. on mobile).
1 reply 0 retweets 0 likes
Well, the assumption is that you’ll be displaying the JPEG anyway, so you either upload the coefficients earlier or you upload the raw pixels later. Most coefficients are zero, so if you can find some way to compress those on upload you win in memory bandwidth.
-
-
Replying to @pcwalton
Ha that's very true if you're displaying it, nice and easy trade-off. I think too much in terms of network servers.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.