The javadoc team has identified performance issues in the javac Name class, particularly when it is used via its `CharSequence` interface (JDK-8263321). The main issue there is that the `CharSequence` is specifically character-oriented, whereas the native form inside javac is a byte[] in modified-UTF8 form. Operations like `.length()` and `.charAt(int)` have "simple" but very inefficient implementations.

It is worth noting from a historical perspective, javac used to only use the byte-oriented API; the `CharSequence` API was retrofitted for JSR 269 (java.lang.model and friends), but since then, it appears that javac is also using the character-oriented API. [~prappo] has instrumentation to show the amount it is being used in a plain-old-javac compilation (i.e. outside the context of use in javadoc.)

Also worth noting that NameTable and Name were originally created for efficient storage of short strings: low overhead and interned. Back in the day, strings were more heavyweight and interned `String`s were "too persistent".

A couple of suggestions for possible investigation.

1. It is already the case that javac supports alternate impls of NameTable, for shared and unshared use. Another alternate would be a NameTable that uses Strings for the underlying storage, although it might still be necessary to have a `NameImpl` that wraps a `String`.

2. Variant of 1 in which the proposed new implementation of NameTable directly uses `String.intern` and avoids any local map within the NameTable implementation.