On Apr 10 2014, at 11:08 , Chris Hegarty <chris.hega...@oracle.com> wrote:
> >> On 10 Apr 2014, at 18:40, Mike Duigou <mike.dui...@oracle.com> wrote: >> >> >>> On Apr 10 2014, at 03:21 , Chris Hegarty <chris.hega...@oracle.com> wrote: >>> >>>> On 10 Apr 2014, at 11:03, Ulf Zibis <ulf.zi...@cosoco.de> wrote: >>>> >>>> Hi Chris, >>>> >>>> Am 10.04.2014 11:04, schrieb Chris Hegarty: >>>>> Trivially, you could ( but of not have to ) use >>>>> java.nio.charset.StandardCharsets.ISO_8859_1 to avoid the cost of String >>>>> to CharSet lookup. >>>> >>>> In earlier tests Sherman and I have found out, that the cost of >>>> initialization of a new charsets object is higher than the lookup of an >>>> existing object in the cache. >>>> And it's even better to use the same String instance for the lookup which >>>> was used to cache the charset. >>> >>> Interesting… thanks for let me know. Presumably, there is an assumption is >>> StandardCharsets is not initialized elsewhere, by another dependency. >> >> Generally it's safe to assume that StandardCharsets will already be >> initialized. If it isn't initialized we should consider it an amortized cost. > > I'm which case why would the string version be more performant than the > version that already takes the Charset? Doesn't the string version need to do > a lookup? There is a cache in StringCoder that is only used in the byte[] getBytes(String charsetName) but not in the byte[] getBytes(Charset charset) case. The rationale in StringCodding::decode(Charset cs, byte[] ba, int off, int len) may need to be revisited as it is certainly surprising that the string constant charset name usage is faster than the CharSet constant. Mike
