A word about the immutability-for-performance paradigm
fhein opened this issue · comments
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.
Ok. I understand, that this is your opinion. But you do not provide any evidence (as usual, if I am allowed to say that).
I'd appreciate, if you would pay more attention to my Lazy Services question than to this one. I do not like that this pokey scope is more about politics than about anything else.
Sure, direct me to wonderland. One or two sentences to explain, what I am missing, were to much engagement.
I read most of the stuff regarding refactoring of SM, Man, I was not quite amused, I think, you are the one to ask, if I want to get answers to build upon. So please ...
It's not that hard to find. Please see http://php-di.org/news/21-php-di-6-compiled-container.html as a starting point.
@bcremer; So, what in particular, does that contribute? I assume, this is not a quizz.
Thanks @bcremer, that was the link I was looking for 👌
Well, it makes PHP-DI quite a lot faster than zend-servicemanager while having almost the same features, for once.
/cc @nicolas-grekas do you by chance have any recent symfony DIC fivures? You did a lot of extremely detailed optimisation work there...
Ok. I read @bcremers link word by word. And I read your last response.
Resume: You seem to don't actually care about Zend\ServiceManager\ServiceManager performance.
Are you the right maintainer of this library 'Zend\ServiceManager'? Really? Do you support progress here as good as you can?
And if you are talking about performance of PHP-DI: Is it as fast as it could be? If there are the same policies in place I assume here (not invented here -> difficult, all progress incorporated is in debt programmed by me), I think not, Maybe they could need some troublemakers also.
What do your statistics say to ServiceManager performing at < 100 microseconde for bulk installation, fully mutable, ...? That's what I am aiming for and that's what I will achieve, once you decide to stop blocking progress?
Resume: You seem to don't actually care about Zend\ServiceManager\ServiceManager performance.
Seriously?
Reading that link with PHP-DI 6 improvements and the tests, it seems that the servicemanager is still one of the best performing containers. And improvements can be made at bootstrap time. Using a caching mechanism and compiling closures sounds very interesting.
I completely agree, Who will deliver? I could. @Ocramius: You complain that you have bills to pay. Who has not? You have, I have. Go!
Would delivery be possible without having any political ambitions in this business? What in particular justifies LazyServicesFactoryFactory's insourcing? I actually do not like such 'thingies' hanging around for no value.
Guys, there is not much room to discuss thesises in the dark. I will have a look at PHP-DI or how it's called, but Zend\ServiceManager with all it's BimBam around is just a few lines of code. To less to talk theoretical.
There is nothing you could not just tryout and find out how optimize in a minute. This is at all more or less easy going.
Silence again? So easy, isn't it?
At the end I am happy that people talk to me at all. 👍
Silence again? So easy, isn't it?
Seriously dude, if you want a fast-paced conversation, I suggest to go outside to a public place and start a discussion about the weather.
I completely agree, Who will deliver? I could. @Ocramius: You complain that you have bills to pay. Who has not? You have, I have. Go!
In OSS "it will be done when someone has time to do it". That's really all there is to it, unless there's a sponsor.
Would delivery be possible without having any political ambitions in this business? What in particular justifies LazyServicesFactoryFactory's insourcing? I actually do not like such 'thingies' hanging around for no value.
Me neither, but I also didn't get to follow the current WIP in this repo (you opened/closed/re-did a lot of patches, multiple times - I'm mostly waiting for them to settle down before considering them)
Guys, there is not much room to discuss thesises in the dark. I will have a look at PHP-DI or how it's called, but Zend\ServiceManager with all it's BimBam around is just a few lines of code. To less to talk theoretical.
No theory, just practice:
- after
__construct, nothing changes anymore - we can perform any number of optimisations between the
__constructcall and the first#has()or#get()call (we are currently limited by mutable definitions)
Please do also change the tone of discussion - you really make it hard to give a remote shit about what you do, and I'm really trying hard to keep it cool, because the work is actually valuable.
Locked because the comments were starting to become quite ridiculous (deleted some, for everyone's sake).