On 10/18/12 7: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.
no "real" tuning yet on the direct buffer case. Just tried to get the
API out for review/comment first.
In any case, I think encode(ByteBuffer,ByteBuffer,int) looks
reasonable and just requires using the idiom to get it right. I'm less
sure about decode returning a boolean. Shouldn't it be an error if
there are bytes remaining after the = padding?
It depends on expectation. Padding partially serves as a "end of base64
byte stream" indicator.
I'm just looking for ways to allow the method return an int to
indicate the number of bytes written to the output buffer (and realize
that we aren't going to get symmetry with the encode method).
Yes, even a "int" return value will not get us the symmetry with
encode(bb, bb). A boolean return provides
a more liberal behavior.
-Sherman
