[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Created] (CODEC-166) Base64 could be faster
From:       "Julius Davies (JIRA)" <jira () apache ! org>
Date:       2013-01-30 23:27:12
Message-ID: JIRA.12630030.1359588344732.218727.1359588432596 () arcas
[Download RAW message or body]

Julius Davies created CODEC-166:
-----------------------------------

             Summary: Base64 could be faster
                 Key: CODEC-166
                 URL: https://issues.apache.org/jira/browse/CODEC-166
             Project: Commons Codec
          Issue Type: Bug
    Affects Versions: 1.7
            Reporter: Julius Davies
            Assignee: Julius Davies
             Fix For: 1.8


Our Base64 consistently performs 3 times slower compared to MiGBase64 and iHarder in \
the byte[] and String encode() methods.

We are pretty good on decode(), though a little slower (approx. 33% slower) than \
MiGBase64.

We always win in the Streaming methods (MiGBase64 doesn't do streaming).  Yay!  :-) \
:-) :-)

I put together a benchmark.  Here's a typical run:

{noformat}
  LARGE DATA new byte[12345]

iHarder...
encode 486.0 MB/s    decode 158.0 MB/s
encode 491.0 MB/s    decode 148.0 MB/s

MiGBase64...
encode 499.0 MB/s    decode 222.0 MB/s
encode 493.0 MB/s    decode 226.0 MB/s

Apache Commons Codec...
encode 142.0 MB/s    decode 146.0 MB/s
encode 138.0 MB/s    decode 150.0 MB/s
{noformat}

I believe the main approach we can consider to improve performance is to avoid array \
copies at all costs.   MiGBase64 even counts the number of valid Base64 characters \
ahead of time on decode() to precalculate the result's size and avoid any array \
copying!

I suspect this will mean writing out separate execution paths for the String and \
byte[] methods, and keeping them out of the streaming logic, since the streaming \
logic is founded on array copy.

Unfortunately this means we will diminish internal reuse of the streaming \
implementation, but I think it's the only way to improve performance, if we want to.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[prev in list] [next in list] [prev in thread] [next in thread]