Re: Base64 decode/encode performance

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Gaetano Mendola" <mendola(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Base64 decode/encode performance
Date: 2008-09-10 14:31:34
Message-ID: e51f66da0809100731q408287b5r582f17b7b37fe7a4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/10/08, Gaetano Mendola <mendola(at)gmail(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ron Mayer 2008-09-10 14:38:14 Re: [PATCH] Cleanup of GUC units code
Previous Message Zdenek Kotala 2008-09-10 14:31:32 Re: using hash index when BETWEEN is specified