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@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
