Review/comment needed for the new public java.util.Base64 class (original) (raw)

Xueming Shen xueming.shen at oracle.com
Thu Oct 18 21:45:31 UTC 2012

On 10/18/2012 07:43 AM, Alan Bateman wrote:

On 18/10/2012 03:10, Xueming Shen wrote:

Hi

Webrev has been updated with following changes (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods (2) some minor spec clarification regarding the "end of decoding" (3) performance tuning. webrev: http://cr.openjdk.java.net/~sherman/4235519/webrev some performance scores: http://cr.openjdk.java.net/~sherman/4235519/score3 -Sherman Have you done any performance tuning on the new methods that encode/decode into an existing ByteBuffer? Just wondering as the direct buffer case seems more expensive that I would expect. It would be interesting to see using the put(int,byte) and fixing up the position at the end would help. It might also be something to look at with the compiler folks.

get(index) and put(index, byte) do help, see 20%+ improvement.

sherman at sherman-linux:~/Workspace/jdk8/test/java/util/Base64$ java PermBase64 200000 1000 j.u.Base64.encode(ba) : 702000 j.u.Base64.encode(bb) : 690024 j.u.Base64.encode(bb, bb) : 910582 j.u.Base64.encode(bb, bb)-D: 1198606 migBase64.encode(ba) : 661271

j.u.Base64.decode(ba) : 797152 j.u.Base64.decode(bb) : 802968 j.u.Base64.decode(bb, bb) : 999577 j.u.Base64.decode(bb, bb)-D: 1472003 migBase64.decode(ba) : 1458450

webrev has been updated accordingly. Now implementations of de/encodeArray and de/encodeBuffer are identical except the access operation.

-Sherman

More information about the core-libs-dev mailing list