[
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581308#comment-13581308
]
Thomas Neidhart edited comment on CODEC-166 at 2/19/13 6:38 PM:
----------------------------------------------------------------
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}
before patch:
{noformat}
MEDIUM DATA new byte[1234]
iHarder...
encode 235.0 MB/s 105 per run=0.00525 decode 84.0 MB/s
encode 235.0 MB/s 105 per run=0.00525 decode 84.0 MB/s
MiGBase64...
encode 316.0 MB/s 78 per run=0.0039 decode 135.0 MB/s
encode 316.0 MB/s 78 per run=0.0039 decode 135.0 MB/s
Apache Commons Codec...
encode 59.0 MB/s 416 per run=0.0208 decode 61.0 MB/s
encode 58.0 MB/s 421 per run=0.02105 decode 61.0 MB/s
LARGE DATA new byte[12345]
iHarder...
encode 233.0 MB/s 529 per run=0.052899999999999996 decode 60.0 MB/s
encode 134.0 MB/s 915 per run=0.0915 decode 63.0 MB/s
MiGBase64...
encode 318.0 MB/s 387 per run=0.038700000000000005 decode 133.0 MB/s
encode 299.0 MB/s 412 per run=0.0412 decode 134.0 MB/s
Apache Commons Codec...
encode 60.0 MB/s 2051 per run=0.2051 decode 65.0 MB/s
encode 59.0 MB/s 2073 per run=0.2073 decode 68.0 MB/s
{noformat}
was (Author: tn):
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
