Greg Smith <g...@2ndquadrant.com> writes:
> While being a lazy researcher today instead of writing code, I
> discovered that the PNG file format includes a CRC-32 on its data
> chunks, and to support that there's a CRC32 function inside of zlib:
> http://www.zlib.net/zlib_tech.html
Hah, old sins keep coming back to haunt one ;-)
Keep in mind that PNG was designed in 1995, and that any speed
considerations in that spec were decided in the context of whether it
would take noticeably longer to view an image downloaded over analog
dialup. That design context also informed a greater interest in error
checking than has been seen in any other image file format before (or
since, I believe).
> And they've already put some work into optimizing its table-driven
> implementation. Seems possible to punt the whole problem of how to do
> this efficiently toward the zlib developers, let them drop into assembly
> to get the best possible Intel acceleration etc. one day.
I would not hold my breath waiting for any such work from either the
zlib or libpng developers; both of those projects are basically in
maintenance mode AFAIK. If we want hardware acceleration we're going
to have to deal with the portability issues ourselves.
FWIW, I would argue that any tradeoffs we make in this area must be made
on the assumption of no such acceleration. If we can later make things
better for Intel(TM) users, that's cool, but let's not screw those using
other CPUs.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
