This week's giveaway is in the Threads forum.
We're giving away four copies of Java Concurrency Live Lessons and have Doug Schmidt on-line!
See this thread for details.
Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Instrumenting complex objects with CompositeData = large performance penalty?  RSS feed

 
Alvin Lim
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have the following code. I wish to monitor TimersContainer objects with JMX, using JConsole.




Here's the problem: Because CompositeData is immutable, and because my timer values are changing rapidly, it is necessary (as far as I know) to create a new CompositeDataSupport object each time a getter is invoked. And since (as far as I know) the getters are getting invoked about once every other second in order to publish the MBean to JConsole, that's a lot of CompositeDataSupport objects being created. Unnecessary object creation is bad for performance, and all these CompositeDataSupports are definitely unnecessary in my opinion.

So here's my question: Does anyone know of any better way to accomplish the above? All I want is to be able to monitor my ThreadSafeTimer objects from within the TimersContainer MBean. I'm not familiar with any design patterns for JMX, so please let me know if the above code is impractical (it seems that way to me).
 
Alvin Lim
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...(cue the sound of silence)...

Maybe I should rephrase my post:

Since CompositeData is immutable, returning it in a getter method will require a new CompositeData instance every time. This definitely has an effect on heap size and hence performance. Is the performance penalty negligible? If not, why will anyone ever want to use the CompositeData type?
 
steve souza
Ranch Hand
Posts: 862
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Creating the CompositeDataSupport object every 2 seconds should never be a performance problem.

Here are some possible alternatives though.

I'm not familiar with jmx, but I am guessing it requires the Object[] and other fields in CompositeDataSupport as part of the spec. If not you could use methods to get the values instead and save you from creating an object. You could simply return an object that has methods that can be called.

If this can't be done and if these objects are only used once for display purposes you could always return the same CompositeDataSupport object and simply update its fields. However, this approach isn't threadsafe (not sure it needs to be). Lack of thread safety is one of many reasons it isn't usually good to allow direct updates to fields.

If your CompositeDataSupport object don't change as often as every 2 seconds, or your client console can afford less real time data (say every 30 seconds) then you could return the same object (in this case 15 times) until the time period has elapsed and then return the new object.

There may be design reasons why you may pick another approach, however I suspect from a permormance perspective your exisitng code is fine.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!