Performance Optimization

27 April 2014 | 0

This weekend, I did some performance testing with ConcurrentLinkedQueue. Then, based on work requirements, I programmed a concurrent primitive array of fixed size, more or less like this:

Performance Test

Further performance tests revealed that it should be about 10% faster than a ConcurrentLinkedQueue. However, when I tried out a more sophisticated version storing and working on about 400,000 of more sophisticated, complex business Objects – here, it turned out my version had pretty much the same performance than ConcurrentLinkedQueue – while, unlike ConcurrentLinkedQueue, my version is only of static size and not type safe.

This taught me two things:

  1.  Never ever guess performance. Always test it. And test it as close as possible to the exact scenario, in which you will use it in production. I have read and heard this often before, but only when you see the difference for yourself, you realize how much of a difference a theory can make to practice.
  2. Even if something IS faster, this must not necessarily be the deciding factor. Things done seldom won’t cost much performance, even when you use a very bad algorithm. Only when done repetitive ( for a major part of a computation), it may make a difference (but also here – this must be tested thoroughly of course!). How does a performance difference of 20 ms hurt (e.g, for saving 100 objects) if the overall computation costs you 10 seconds for each iteration?

Leave a Reply

Your email address will not be published.