On Wed, Jan 30, 2013 at 3:35 PM, sebb <seb...@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) <j...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
