You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Thomas Neidhart (JIRA)" <ji...@apache.org> on 2013/02/19 15:33:13 UTC

[jira] [Commented] (CODEC-166) Base64 could be faster

    [ https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581308#comment-13581308 ] 

Thomas Neidhart commented on CODEC-166:
---------------------------------------

With the latest patch I get these figures:

{noformat}
 MEDIUM DATA new byte[1234]

iHarder...
encode 237.0 MB/s 104 per run=0.0052    decode 83.0 MB/s 
encode 237.0 MB/s 104 per run=0.0052    decode 83.0 MB/s 

MiGBase64...
encode 320.0 MB/s 77 per run=0.00385    decode 132.0 MB/s 
encode 316.0 MB/s 78 per run=0.0039    decode 132.0 MB/s 

Apache Commons Codec...
encode 184.0 MB/s 134 per run=0.0067    decode 85.0 MB/s 
encode 185.0 MB/s 133 per run=0.0066500000000000005    decode 85.0 MB/s 

  LARGE DATA new byte[12345]

iHarder...
encode 235.0 MB/s 525 per run=0.0525    decode 83.0 MB/s 
encode 234.0 MB/s 526 per run=0.0526    decode 83.0 MB/s 

MiGBase64...
encode 314.0 MB/s 393 per run=0.039299999999999995    decode 134.0 MB/s 
encode 314.0 MB/s 392 per run=0.039200000000000006    decode 134.0 MB/s 

Apache Commons Codec...
encode 187.0 MB/s 660 per run=0.066    decode 90.0 MB/s 
encode 187.0 MB/s 659 per run=0.0659    decode 90.0 MB/s 
{noformat}
                
> 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
>
>         Attachments: base64bench.zip, CODEC-166.draft.patch, CODEC-166.patch, CODEC-166_speed.patch
>
>
> 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