Name.contentEquals() performance

[Joseph D. Darcy]

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
>