[poppler] Speed improvements - chapter eleven

[Krzysztof Kowalczyk]

On 9/6/06, Jeff Muizelaar <jeff at infidigm.net> wrote:
> On Wed, Sep 06, 2006 at 12:48:16AM -0700, Krzysztof Kowalczyk wrote:
> > Frankly, I was disappointed that it's only ~~5%. I was expecting much
> > more. It turns out that the culprit is current implementation of flate
> > stream, which is frequently used to compress streams inside PDFs. It
> > decompresses data in very small chunks (e.g. 8 bytes on average per
> > getBuf() call in my test) so we don't save nearly as much as if we
> > were getting, say, 256 bytes at a time. I'm working on improving that
> > as well, but this change lays the necessary foundation.
>
> It would also be interesting to see the effect that a version of the
> zlib based FlateStream converted to this interface has on performace. My
> guess (and hope) would be that the zlib code has been optmized more
> heavily than the inflate code in poppler.

Yes. Two things on my todo list is to compare the speed when using
internal jpeg decoding vs jpeg lib and internal deflate vs. zlib. So
far I was only working with internal jpeg/deflate code.

I haven't looked deeply at your recent zlib patch but it's possible
that after adding getBuf() call, it'll be possible to go back to
reading more at a time, because it supports a way for clients to go
back in a buffer. I was struggling with this problem (not reading too
much from a stream) when I was making my getBuf() changes but I think
I got it right.

-- kjk