[concurrency-interest] good design vs performance (object creation)

Ian Rogers ian.rogers at manchester.ac.uk
Mon Dec 28 12:00:55 EST 2009

Hi Peter,

2009/12/27 Peter Veentjer <alarmnummer at gmail.com>:
> Hi dhinji,
> This is the standard answer i give to developers as well and in most cases
> it is very practical and good.
> But i already spend a lot of time pinpointing performance problems in system
> and i found out that removing object creation often leads to a considerable
> performance improvement if its done millions of times a second. I found out
> that eventually object creation and/or cas communication caused the
> bottleneck and not the rest of the code.

When you are doing your performance work are you using a "warmed up"
JVM? A JVM will try to prove that an object doesn't escape a method
and/or a thread. Such knowledge can allow the JVM to avoid locking
thread-local objects and to perform what's known as scalar replacement
of objects - iterators being the prime example of what gets replaced.
With scalar replacement of objects a simple iterator with a next field
will have that field become a local variables and the get/put field
operations performed on it replaced with local variable accesses. If
you write the iterator to a field or pass it around to large methods,
then the JVM's compilers need more time to perform analysis as scalar
replacement optimizations can only be performed conservatively. In
general GC is very cheap, you only pay a cost for live objects. If you
do have a genuine performance issue with a JVM then you should
probably file a bug, this gives best performance to everyone and you
cleaner APIs.

For more information on performance why not check out Cliff Click's blog [1].

Ian Rogers

[1] http://blogs.azulsystems.com/cliff/

More information about the Concurrency-interest mailing list