[
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581528#comment-13581528
]
Julius Davies commented on CODEC-166:
-------------------------------------
Hi, Mikael,
I don't think there's been any discussion in private between Apache-Commons
committers --- at least none that I was involved in. We try to do everything
in the open. There was some discussion on the ML instead of in the bug here
(a reply thread to my original commit, which creates an automatic email to the
ML).
Your comment here in the bug-tracker helps, btw. Always nice to know that the
original project team supports a fork.
---
Question for Thomas:
Would you mind attaching your micro-benchmark? Looks like you made some good
improvements to it!
---
Comment for everyone,
Thomas's patch will help us in any case (e.g., it will improve streaming
performance if we take my patch; it will improve all performance if we don't).
So let's take Thomas's patch for sure, and continue discussing the MiGBase64
fork I've prepared.
> 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
