[ https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582444#comment-13582444 ]
Thomas Neidhart commented on CODEC-166: --------------------------------------- Hi Julius, the only change I did was as described on the mailinglist: use (part) of the result in some kind of calculation to prevent it from being optimized away: {noformat} long d = 0; long start = System.currentTimeMillis(); for (int i = 0; i < FACTOR * REPS; i++) { encoded = Base64.encodeBase64(data); d += encoded[i % encoded.length]; } printEncodeStat(start, data, d); {noformat} The value d is then passed to the print method to be output. This of course for all occurrences of this pattern. > 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.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