Folks, Comments inline....
Mike. Simon Nash wrote:
By changing the lifecycle of the target instance I mean that it would be created eagerly (on source reference creation) rather than lazily (on source reference invocation) as is done currently. From looking at the new code I believe this is what would happen. (If I have misunderstood, please correct me.) An example of the difference is that if a conversational scoped component A references a stateless scoped component B and invokes it ten times through the same reference within the same conversation, at present we would create ten copies of B, one per invocation. With this new code, we would create one copy of B at the time that the A instance is created. This changes the lifecycle of B. It is arguably a change for the better, but it is still a change.
My concern is whether the existing code has some deep-rooted dependence on the lifecycle of component instances. This may well become a problem over time.
Now consider a stateless instance with references to other stateless components. For a long chain of references and services (A -> B -> C -> D -> E -> F), all six objects would be created at the same time when the A instance is created, rather than just creating the A instance and a proxy for B. Depending on the execution path through A, it's possible that five of these six objects will never be used. This doesn't seem good to me. I'm not surprised that our tests don't pick this up, because it isn't easy to test for this kind of thing. However, it can cause resource and performance issues in a real-world environment because of an excessive number of object creations and garbage collection cycles.
This is a good point and it emphasises that optimisation must be looked at "in the large". Object pooling is one technique that is used in servers to deal with the problem of excessive creation of objects. It applies even if objects are only created "on demand" since if a new object is created for each method invocation, that can mean a huge heap of objects too.
I note that the use of proxies actually creates double the number of objects - one proxy and one target for each invocation...
One way to get the best of both worlds could be to inject a proxy initially and replace it with a direct instance pointer when the proxy is first invoked. This will need more code than the current proposed approach, but I think it may be worth doing for the efficiency benefits. Ideally we would prototype different approaches to see which one yields the best tradeoff in terms of overall execution efficiency and resource consumption. We don't have time to do this before the 1.0 release.
I agree with the sentiment that this needs more time. Optimisation is no easy trick. Unless there is some big performance problem right now,it can be safely left for future work.
Simon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
