On Sun, 28 Apr 2002, marc fleury wrote: > |because an object name contains a set of properties that need to be > |parsed and may also be a pattern which needs to be determined > > right the value=name pairs > > |the current implementation does this eagerly at object name creation > |time > > can we do this lazily? can't we build equality and hash on the FULL string? >
no, we need a canonical presentation for equality check (because the "name" is a set of properties, not just an array of characters.. we need to sort the properties before we can check for equality) > it strikes that the eager parsing is silly (eats up 50% of the time !!!) and > only really useful in querying? Can you think of optimizations? the optimizations that we can do inside ObjectName would only include possibly optimizations to Java's string handling, maybe replacing generic collections with type specific ones, and avoiding Collections.sort() (I don't know how it is implemented or how well it performs). However, the problem with even these optimizations is that Sun plans to push JMX as part of JDK from the next 1.5 version on. They however have no plans to publish an SPI which means whatever is inside javax.management packages will from the next version on be Sun's implementation. And as you and I well know, Sun's implementation isn't exactly performing or industrial strength. The question at the moment is, why do you need to create an object name per invocation? Is it possible to cache the object names by mapping them to *real* identifies as opposed to this property nonsense? (how many MBean's do you imagine having in your server, could you create the object names for them on the server side and lookup the same instances from a "cache" -- I know it sounds ass backwards but given then future plans on JMX it would be best to avoid too much reliance on the JMX classes themselves. -- Juha _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
