Review/comment needed for the new public java.util.Base64 class

[Xueming Shen]

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