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

Peter Veentjer alarmnummer at gmail.com
Sat Dec 26 19:00:10 EST 2009

Hi Guys,

although the question is not directly concurrency related, I want to
place it on this mailinglist because here are a lot of guys that
encounter the issue from time to time.

I'm currently working on a STM implementation and one of the things
that I have found out is that object creation can cause quite a big
slowdown, especially if done
millions of times per second (e.g. 1M to 20M times a second)  If I
look at the code of java.util.concurrent I see a lot of
nodes/iterators being created for example and this can
be a great thing for good oo design but my experience is that it can
cause a considerable slow down.

My question is: how much should the design of a class be influenced by
preventing object creation? I'm at the point where I need to rewrite
the same algorithm
multiple times for different datastructures (e.g. array based versus
map based.. where an array is faster for very small collections). I
could create an ArrayIterator
so that the algorithm is able to work with iterators and it doesn't
matter which data structure is used, but it requires an additional
iterator object. I also know that
garbage collectors are quite smart and that very short lived objects
are very cheap to be garbage collected. I also know that some modern
jvm's are able
to allocate objects in the stack instead of the heap, so even less
worries about gc overhead.

I need some feedback/guidelines from developers that have experienced
this in the trenches and really know what they are talking about. How
for should one go?
I would be very happy to stop ruining my code... but on the other side
I also want a good performance


More information about the Concurrency-interest mailing list