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().