Ocramius
commented
6 years ago Disagree here: if the map of service definitions is known upfront (and doesn't change), then we can introduce a lot of interesting optimisations.
For example:
- Compiled containers
- Hashing config to determine heavy operations only once per deployment
- Eager service definition validation (cached)
Right now, we can't do that because of the extremely messy setup:
- set* methods in the public api
- inheritance-bassd config
Move all bootstrapping to separate named constructors and most of these problems just go away, plus proper service definition design is enforced (post-initialisation overrides are 99.999% a design issue, see https://igor.io/2013/03/31/stateless-services.html )
From my PoV, all public API that leads to internal configurationchanges should be deprecated and dropped.
A much simpler migration path is to work towards immutability, then make these secondary configuration approaches expensive and only optimise the named ctors.
On 8 Feb 2018 07:02, "Frank Hein" notifications@github.com wrote:
Immutability may be a last ressort in order to increase performance. But I am not sure if this property can significantly contribute to performance at all.
Current master, let's assume it was mutable (i.e providing public API's deleteService, deleteFactory et al), this mutability would cause almost no negative performance impact and would cost nothing at all (more or less). That's a statement, I'd be happy to proof that, if there were any demands for a mutable servicemanager.
Current ServiceManager implementation is slow enough, that immutability is not a topic to discuss at all if performance is the issue. Performance gains (by several 100%) can easily get achieved omitting that discussion.
From my user's point of view I'd say: I did never care about ServiceManager being mutable or not. It was set up from some accumulated configs. I always used that only, and never wanted to change it. So immutablity never became an issue,
If there are use cases, where people want to change service manager configurations at runtime, I'd say, this capability could be provided at almost no cost. But I'd recommend to rather review the application design. There might be some flaws.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zendframework/zend-servicemanager/issues/255, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakPC15vm72IVoK8tvt2xQz7jrvccoks5tSo3jgaJpZM4R92BC .
fhein
bcremer
geerteltink
Immutability may be a last ressort in order to increase performance. But I am not sure if this property can significantly contribute to performance at all.
Current master, let's assume it was mutable (i.e providing public API's deleteService, deleteFactory et al), this mutability would cause almost no negative performance impact and would cost nothing at all (more or less). That's a statement, I'd be happy to proof that, if there were any demands for a mutable servicemanager.
Current ServiceManager implementation is slow enough, that immutability is not a topic to discuss at all if performance is the issue. Performance gains (by several 100%) can easily get achieved omitting that discussion.
From my user's point of view I'd say: I did never care about ServiceManager being mutable or not. It was set up from some accumulated configs. I always used that only, and never wanted to change it. So immutablity never became an issue,
If there are use cases, where people want to change service manager configurations at runtime, I'd say, this capability could be provided at almost no cost. But I'd recommend to rather review the application design. There might be some flaws. There are flaws, definitely.
Immutability does not improve performance at all. And it does not open areas of 'research' regarding performance. Mutability almost comes for free. Mutability is a requirement which can be satisfied almost trivially.