You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2013/01/31 00:35:11 UTC
Re: [jira] [Updated] (CODEC-166) Base64 could be faster
The Fix version should only be added when the issue has been fixed,
and should indicate the release in which the fix is available
On 30 January 2013 23:33, Sebb (JIRA) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Sebb updated CODEC-166:
> -----------------------
>
> Fix Version/s: (was: 1.8)
>
>> 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
>> Attachments: base64bench.zip
>>
>>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jira] [Updated] (CODEC-166) Base64 could be faster
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Apr 28, 2013 at 12:50 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 31/01/2013 00:35, sebb a écrit :
> > The Fix version should only be added when the issue has been fixed,
> > and should indicate the release in which the fix is available
>
> Just noticed this message, the 'Fix version' field can be set before
> fixing the issue, this is necessary to build to roadmap with JIRA and
> plan for the future releases.
>
>
+1, I've always set Fix version to indicate intent that this should be
fixed in that version.
Hen
Re: [jira] [Updated] (CODEC-166) Base64 could be faster
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 31/01/2013 00:35, sebb a écrit :
> The Fix version should only be added when the issue has been fixed,
> and should indicate the release in which the fix is available
Just noticed this message, the 'Fix version' field can be set before
fixing the issue, this is necessary to build to roadmap with JIRA and
plan for the future releases.
Emmanuel Bourg
Re: [jira] [Updated] (CODEC-166) Base64 could be faster
Posted by Julius Davies <ju...@gmail.com>.
On Wed, Jan 30, 2013 at 3:35 PM, sebb <se...@gmail.com> wrote:
> The Fix version should only be added when the issue has been fixed,
> and should indicate the release in which the fix is available
>
Ah, thanks for the tip! I won't make that mistake again.
Since it was available to edit during the 'Create Issue' form on JIRA,
I thought maybe it could be for intended version.
yours,
Julius
> On 30 January 2013 23:33, Sebb (JIRA) <ji...@apache.org> wrote:
>>
>> [ https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Sebb updated CODEC-166:
>> -----------------------
>>
>> Fix Version/s: (was: 1.8)
>>
>>> 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
>>> Attachments: base64bench.zip
>>>
>>>
>>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
yours,
Julius Davies
604-222-3310 (Home)
$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org