Name.contentEquals() performance

[Ron Shapiro]

Jon - in reference to your comment about the use of contentEquals - I'm for
the most part seeing this in code that lives outside of javac (annotation
processors & ErrorProne checks), where we are only aware of
javax.lang.model.element.Name, so no contract around interned-ness. In many
cases, we're checking the contents against a string constant (or a
Class.getName() call).

If the intention is to create an interned string, maybe it should store the
string directly instead of the utf bytes?

On Wed, Oct 10, 2018 at 9:18 PM Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> Is String creation for other types done as a guard against possible
> concurrent modification?
>
> -Joe
>
> On 10/3/2018 11:48 AM, Jonathan Gibbons wrote:
> > It is very depressing that Name.contentEquals actually creates
> > strings. I would have expected it to iterate over the code points of
> > the items being compared.
> >
> > It is also somewhat depressing that .contentEquals is being used so
> > much, because the intent of the Name class is to function as an
> > interned string.
> >
> > -- Jon
> >
> > On 10/03/2018 06:22 AM, Maurizio Cimadamore wrote:
> >>
> >>
> >> On 03/10/18 14:16, Maurizio Cimadamore wrote:
> >>> (That said, out of curiosity I tried to instrument the JDK build to
> >>> see how many names were created (this is a bit hard given that the
> >>> build internally reuses java compilers using the sjavac server), but
> >>> name creation seem to peak at around 33K, which would give an
> >>> overhead of a couple of hundred of kB for an extra field like the
> >>> one you suggest, which doesn't seem excessive in terms of footprint
> >>> increase)
> >> Actually, now that I think more, if you store the toString() result
> >> in an extra field, while the footprint of the Name class (shallow
> >> size) won't change much (8 more bytes per instance), we could
> >> potentially be talking about 33K more (in the JDK build case) strings
> >> be retained by the javac code - which is probably going to balloon up
> >> the memory footprint cost significantly.
> >>
> >> Maurizio
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20181231/5bacfeb1/attachment.html>