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. 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.
Michael Rickard Öberg schrieb: > Niclas Hedhman wrote: >> EntityComposite --> I think the answer might not be as simple as you >> portrayed. Even if Entities are short-lived, in web applications you >> might have hundreds or even thousands of requests in progress at the >> same instance of time, in which case the number of objects becomes >> large, and the explosion of objects actually happens. >> For other types of applications, it might be true that extremely low >> numbers of Entities (ValueComposites probably have a similar >> argumentation) are present, but where speed is paramount. > > Well, if you look at web applications, I think the vast majority of > method calls are going to be access of properties and associations, > which don't have concerns. So, that can be optimized away completely. > >> So, I think the solution is to provide the "Turbo" button for users to >> turn on or off for each app, or even each type. How that "button" is >> implemented is a different story. >> >> IMHO, is this really a "design decision"??? Isn't this largely an >> internal implementation detail, which we can introduce later? > > For the most part it's an internal implementation detail. The only > impact on design it might have is that the dereference() method is not > necessary if concerns point to the correct proxy in the first place for > @This injections. > > /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
