It is still possible to use a proxy for thechain, that is replaced on the first call with the instatiated chain and so you have no additional synchronization / lookup costs as the replacement is done by the proxy that is gone afterwards.
Michael Rickard Öberg schrieb: > 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 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
