Michael Hunger wrote: > I think creating lazyly a new instance would work best. So there is > no upfront cost involved for methods and concerns that are never > called.
Well, that may seem like the logical choice, but as usual, it depends! Consider ServiceComposites, where it will only be one instance ever. Instead of having a lazy-instantiation using volatile/synchronized double-locking, which impacts the performance of EVERY single call, it would be trivial to instantiate the concern chains for all methods at startup and assign those statically. Then there would be no synchronization costs involved, and for services which are invoked frequently that is a big deal! > If we could manage that the objects created don't go to the > heap outside of young generation (narrow scope to method local > blocks) they may not even incurr GC penalties. It shouldn't be a > problem to do a performance test spike on that (if neccessary). The > simplest approacht should suffice for now. The internal > implementation detail should just not leak out to the API so that it > can be changed later if necessary of even adapted > dynamically/configuratively during application runtime/deploment. Yes, I think in the end we may have to try different methods and simply do performance benchmarks to compare speed vs memory in the different cases. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
