On 9/10/08, Gaetano Mendola <[EMAIL PROTECTED]> wrote: > I have been experimenting with some base64 encoding/decoding implementation. > > I find out that the one at http://code.google.com/p/stringencoders is the > best > obtaining a 1.3 speedup vs the postgres one. > > Do you think is worth to submit a patch that replaces the postgres base64 > implementation > with this one?
(Note: the b64encode there reads 3 chars at a time, b64decode int32 at a time.) There are 2 killer problems: - decode does not seem to handle architectures that segfault on unaligned int32 accesses. - decode does not allow whitespace in input string. If those are fixed it's question of if the 1.3x speed if worth more complex code with big lookup tables. If you want to optimize, it seems more worthwhile to add additional loop to current code that reads 3 or 4 chars at a time, before the current single-char loop. The decode loop may thus even optimize to int32 fetching on x86/64 with reasonable compiler. Handling whitespace with such code is doable, but will the code be clear enough? -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
