Understood. I do have the code:-) but I'm hesitated to go SharedSecrets
simply for
performance gain of a utility method. This definitely can be addressed
if it turns out
to be a real issue standing in critical path.
-Sherman
----------------------------------------------------------------------------
sherman@sherman-linux:~/Workspace/jdk8/test/java/util/Base64$ java
PermBase64 200000 1000
j.u.Base64.encode(ba) : 528745
j.u.Base64.encodeString(ba): 739703
j.u.Base64.encode(bb) : 486216
j.u.Base64.encode(bb, bb) : 538544
j.u.Base64.encode(bb, bb)-D: 850947
migBase64.encode(ba) : 659474
vs
sherman@sherman-linux:~/Workspace/jdk8/test/java/util/Base64$ java
PermBase64 200000 1000
j.u.Base64.encode(ba) : 519391
j.u.Base64.encodeString(ba): 964854
j.u.Base64.encode(bb) : 490138
j.u.Base64.encode(bb, bb) : 539027
j.u.Base64.encode(bb, bb)-D: 786438
migBase64.encode(ba) : 660572
-Sherman
On 10/19/2012 04:59 PM, Mike Duigou wrote:
For me the greater concern, which is hard to measure, is the GC pressure added
by the discarded byte array.
Mike
On Oct 19 2012, at 17:03 , Xueming Shen wrote:
I see a 20% performance gain on server vm if switch to pure char[] based
encoding
and then use the sharedSecrets to avoid the copy. The dis-advantage is (1) have
to
use the sharedSecrets and (2) can't share the same between the encode(byte[])
and encode(String).
Anyway it appears to be an alternative for performance improvement.
-Sherman
On 10/18/2012 01:07 PM, Mike Duigou wrote:
I wonder if there would be advantage in using a SharedSecrets mechanism to
allow construction of a String directly from a char array. The intermediate
byte array seems wasteful especially for what is likely to be a heavily used
path.
Mike
On Oct 17 2012, at 19: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
