Name.contentEquals() performance

[Jonathan Gibbons]

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