StandardCharset vs. StandardCharsets

[Xueming Shen]

On 05-07-2011 上午 9:00, Rémi Forax wrote:
> On 05/07/2011 02:17 PM, Ulf Zibis wrote:
>> Hi all,
>>
>> please excuse, that I have still problems to accept this additional 
>> class, but +1 for the plural name.
>>
>> If those charset constants are there, people _will use_ them without 
>> respect on the existing _performance disadvantages_.
>> A common typical use case should be: String.getBytes(...)
>> On small strings there is a performance lost up to 25 % using the 
>> charset variant vs. the charset name variant. See:
>> http://cr.openjdk.java.net/~sherman/7040220/client
>> http://markmail.org/message/2tbas5skgkve52mz
>> http://markmail.org/thread/lnrozcbnpcl5kmzs
>>
>> So I still think, we should have the standard charset names as 
>> constants in class j.n.c.Charset:
>> public static final String UTF_8 = "UTF-8"; etc... 
>
> Using objects instead of string is a better design.
> I see the fact that the String method variants that takes a Charset 
> are slower that the ones that use a String
> as a performance bug, not as a design issue.
>
> The String method that takes a Charset should reuse the class-local 
> decoder
> and the performance problem will go away.
> (The analysis in StringCoding.decode(Charset, ...) (point 1) forget 
> that initializing a decoder has also a cost)

I do know the "slowness" is from initializing cs.newDe/Encoder():-) But 
it is just not "easy" to cache
the de/encoder in this case. There is no guarantee that the cs passed in 
this time is the same one
you had last time, even the name might be the same. Or even the cs this 
time is indeed the same
instance you had last time (you did the cache), there is no guarantee 
the dec/enc returned from
newDecoder()/Encoder() this time will be the same one in your cache, 
until you invoke the
newDecoder()/Encoder() , get the enc/dec and compare to the on in your 
cache, but then why cache
it:-) Something you can do is to do the cache if the cs passed in is 
indeed the one from our own
charset repository (can be trusted that would not do something tricky), 
you can do this by invoking
getClassLoader0() == null, which is expensive, I kinda remember the 
measure showed this might
not be something worthing doing last time when I was there. Sure, those 
charsets in
StandardChsets can be treated specially, if desirable, probably only the 
ascii, iso8859-1 and utf8,
such as

if (cs == StandardCharsets.UTF_8 || cs == StandardCharsets.US_ASCII...) {
...
}

Will do some measurement later to see if to separate the "else" part in 
a side method will speed
up a little, we can do that if the inline does help, but not for 7:-)

Thanks!
-Sherman

> Rémi
> PS: also the else part of if(c instanceof ArrayDecoder) should be in a 
> side method to ease
> the inlining of decode().
>