I don't see how this is relevant for production usage (when the container is generated), and the building process can be split up into packages based on service groupings or something at some point i suppose.
On Tue, Feb 19, 2013 at 5:55 PM, Lukas Smith <sm...@pooteeweet.org> wrote: > > On Feb 17, 2013, at 21:30 , Larry Garfield <la...@garfieldtech.com> wrote: > > > Greetings, Symfonians. > > > > I know that there is some difference of opinion within the Symfony world > about making controllers ContainerAware vs making them fully injected > services. There's decent arguments both directions. We're discussing that > self-same issue in Drupal right now: > > > > http://drupal.org/node/1915774 > > > > Generally, there seems to be a sense that making them services would be > "better". However, one concern we have there is the scalability of the DI > Container. We're using a PHP compiled container, which from previous > conversations Lukas Smith has told me should scale fine to a thousand or so > services before you need to start worrying. > > > > Of course, "about a thousand" is a reasonable approximation for the > number of controllers a small Drupal site has[1]. (A powerful and complex > administration system means lots of pages, which means lots of > controllers.) That means if we establish a pattern of always making > controllers services, rather than ContainerAware, we will run into the > point where we have to start worrying about the Container's scalability > with just Drupal core. That's before getting into contributed modules, > which a typical site has in the dozens. And then there's all of the "real" > services that we will have. Then there's EventSubscribers, which are > registered as services. > > > > That makes the potential scalability of the Container a rather pressing > question for us. > > > > Does anyone have any hard data on just how far the Container will scale > before compiling it becomes a memory or CPU hog, or the runtime parsing > cost gets too big to handle, etc? Just how far have people pushed the > Container before it fell over? We're going to be pushing it pretty far, so > want to make sure it won't fall over. :-) > > > > (And if you have more direct thoughts on ContainerAware controllers vs. > controller services, please do weigh in on the issue above.) > > i have faint recollections that someone once made some benchmarks before > we want to 2.0 but it wasnt totally conclusive IIRC. it was enough that we > didnt make commands services, but it also did not make anyone too > considered about moving logic from controllers into services. so better do > your own benchmarks with todays code. > > regards, > Lukas > > -- > -- > If you want to report a vulnerability issue on Symfony, please read the > procedure on http://symfony.com/security > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Symfony developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to symfony-devs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- If you want to report a vulnerability issue on Symfony, please read the procedure on http://symfony.com/security You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en --- You received this message because you are subscribed to the Google Groups "Symfony developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to symfony-devs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
