On 04/10/2014 11:08 AM, Chris Hegarty 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?
String version has the cache mechanism of charset -> CharsetDe/Encoder, so if
cache hits, you don't need to have String->Charset lookup.
We don't cache the "external" charset though for de/encode(Charset ...), so we
always need to create a "new" CharsetDe/Encoder everytime the de/encode()
method gets invoked.
-Sherman
