String.intern use in SIPHeader is quite CPU intensive about jsip HOT 2 OPEN

Yes this is a known pattern and a number of things have been tried over the years. In general profiling a JVM for CPU in apps that are not CPU-bound is not worth it. Most jsip apps I've seen are memory bound. I remember avoiding intern() had an adverse effect on garbage collection. You may gain some speed until the first major GC event hits you. And garbage collection is not subject to a Java profiler so it gives inaccurate results.

Not familiar with the results of this particular patch here but it's possible that without synchronisation it had some issues, while with synchro it would be similar to intern().

There are new garbage collectors now and it may be worth re-examining the issue, however I wouldn't trust a JVM profiler to conclude this is a bottleneck, this needs a native profiler to capture GC codepaths under sustained load. You may be trading CPU for GC stress.

from jsip.

Thanks for the quick reply, that's all interesting.

I didn't appear to see major GC trade-offs when performing the same tests without the SIPHeader .intern(), but that was still with Jprofiler which only shows general GC activity. (And a JVM running with the G1 GC, FWIT).

Interesting point about using a native profiler to get a better GC picture, thanks.

from jsip.