I'm not certain that de-serializing is going to be any faster than XML parsing. Even with Externalizable, Java serialization is slow. Serialization can save bytes but not necessarily cycles. Not necessarily bytes either, depending on the circumstance. ERH has blogged about this in the past.
I suspect the largest slice of time is class loading, which you pay for either way. I think we can speed up HiveMind in a few ways (off the top of my head, no order, some undesirable): 1) Change the OuterProxy/InnerProxy pair down to just a single Proxy. That's one less class to create for each service. The cost is the need to synchronize the method that will just-in-time instantiate the service. We had a discussion about this, and the ephemeral threading bug behind the scenes, last week. 2) Instantiating services with BuilderFactory involves a large number of reflective calls. We have discussed the idea of delegating service construction out to static methods of a per-module class. This should reduce the cost of instantiating a service down to a single reflective call. 3) Wait for CPUs to get faster :-) 4) Latch HiveMind to JDK 1.5 and start using read/write locks instead of synchronization for greater parallelism (won't help startup, may hurt it). 5) Streamline parsing further, perhaps by eliminating the use of regexp validation of some attributes. 6) Ditch commons-logging in favor of something homebrew, or JDK 1.4 logging, or that alternative to commons-logging (http://www.slf4j.org/) There may be other areas to investigate. Are we using proper buffers when parsing the XML? You get a pretty big performance boost by wrapping a FileInputStream inside a BufferedInputStream [actually, I've tested this with the debugger, and we seem to have a decent stack of input streams by the time we get into the parser code]. I've circled around this a number of times. I've thought about moving most of the HiveMind logic into a build phase that would generate classes at build time (as in, no XML parsing or class creation at runtime) ... but that makes the build/deploy/test cycle much more complex and the runtime structure of the application more rigid. Also, I'd like to keep HiveMind 99.9% backwards compatible (Tapestry backwards compatibility is already a thorn in my side, and of the Tapestry users' sides). I noticed that it's 20% parsing time, 80% inside startup code. Again, I think we need to see more of what's going on inside the 80% and I suspect most of it is class loading time. How much of that is Javassist class creation is another question. On 6/25/06, Knut Wannheden <[EMAIL PROTECTED]> wrote:
Achim, > > - I see that you're using the concept of natures on modules, > > extenstion points and extenstions, where XML would be an example of > > such a nature. That looks like a very interesting idea. As you don't > > have a defined interface for these natures it seems to me that they're > > more like adapters. > > > I was inspired by the eclipse natures (for example a tomcat nature) > which provide > additional information to a project. The adapter pattern usually deals > with conversion of > incompatible interfaces which is not the case here. > I see. What confused me was that the way I've seen Eclipse project natures being used is that they must implement a defined lifecycle interface which allows them to hook in certain behaviours when the nature is first added and when it's removed. It seems like your natures can really be any POJO and can / will be used by any other object whenever required. I thought this was more similar to the IAdaptable interface used throughout the Eclipse APIs (according to the following article this is really an example of the extension object pattern: http://www.artima.com/lejava/articles/designprinciples.html). Also EMF is using something similar they call adapters but aren't truly adapters in the GoF pattern style. > > - The configuration points also seem to declare a constructor which is > > responsible for constructing the container object. Is here the idea > > that a configuration can have multiple containers (as currently with > > Map and List) and thus constructors? > > > No, I decided to break backward compatibility here. A configuration must > have exactly > one type. IMO the support for mappable configurations in hivemind 1.x is > simply a concession > to the need for different configuration types. If you need a > configuration as map and list, > then define and inject it as map and call map.values(). Migration is > quite easy. > OK. I wasn't quite clear on the idea there. > > - In the org.apache.hivemind.definiton package the concrete > > ExtensionDefinition objects are not owned by the *ModuleDefinition* > > object but instead directly to the respective ExtensionPointDefinition > > object. I get the impression that this couples modules in such a way > > that it isn't possible to define them independently. IMO it would be > > better to keep the ExtensionDefinition objects under the > > *ModuleDefinition* object and have a reference by ID to the > > ExtensionPointDefinition. > > > Both is possible. The direct addition to the extension point is the most > comfortable way > if you define a complete module. Additionally it is possible to define > "unresolved" extensions that > reference the points by id. The corresponding methods are defined in > RegistryDefinition > in the moment and here you are right, they should be moved to > ModuleDefinition. IMHO I think the "comfortable way" could be implemented by a implementation of the registry definition API specific for defining modules in plain Java code (as in your example). > > - IMHO defining the *Definition objects as interfaces would have some > > advantages. > > > Ok, but I would introduce interfaces when the api is stable. > Makes perfect sense. > > Anyway I think this is looking very good. Let me know if there's > > anything I can help you with. > > > A most welcome addition would be a refactoring of the dependency injection. > It's coupled with the xml specific BuilderFactory in the moment, which makes > it difficult to reuse with pure java or annotated java modules. > Maybe we could reuse code or the concepts from commons proxy for this. --knut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
