-- Endijs Lisovskis <[EMAIL PROTECTED]> wrote (on Tuesday, 26 August 2008, 11:14 AM -0700): > > I'm just wondering... all those new components that are added to ZF - are > they completely independent - or you need to alter some core components in > order for new ones to work? I suppose there are new components that require > core changes and ones that don't require. But maybe i'm wrong. I'm not ZF > developer - so I don't really know how all this is built one core level. > Question is - if there are new components that require core changes - maybe > there is possibility that those changes affects speed even if new components > are not used. If core changes are never needed, then it's 100% clear, that > new features can't affect speed if they are not used.
As a general rule, we don't allow new components that necessitate changing existing components to depend on them, unless there's a _very_ good reason (for instance, if you need to add plugin capabilities, or are refactoring an existing component to spin off functionality to a new component). We _did_ have a performance regression initially with 1.6.0RC1 due to changes in the router to allow hostname-based routing. However, those working on the component came up with a better solution for RC2 that not only eliminated the problems, but also provided a path for speeding up routing for later releases. To this date, we haven't focussed much on performance, but primarily on functionality. As the adage goes, "premature optimization is the root of all evil;" it makes more sense to get a solid and tested code base first, and then focus on optimizing later. > I cant imagine how you will be able to provide methodology for different > framework tests, but if you will achieve this, then that would be amazing. > I think that very important and interesting thing would be to see how each > components are becoming faster and for how much. I know - example is not > most accurate, but each jQuery release comes with not only new features > lists, but with tests results, which represents how much new jQuery is > faster than previous one. That would be great to see in ZF changelogs. As mentioned previously, the focus for 1.7, internally, is performance. After we get a reasonable benchmarking suite worked up, we can publish this for others to use -- and can also start testing each ZF release to see what improvements/detriments were made. > Matthew Weier O'Phinney-3 wrote: > > > > -- Endijs Lisovskis <[EMAIL PROTECTED]> wrote > > (on Tuesday, 26 August 2008, 10:27 AM -0700): > >> At first let me say THANKS for your reply! I was not expecting such a > >> long > >> comment. I will definitely look at ZF 1.7 features and optimizations. > >> > >> I can't give you any links to articles where someone is pointing out that > >> ZF > >> is slow, except one you already gave. But each time when I talk about > >> frameworks and ZF in particular I receive negative reactions and all of > >> theme are because of doubts about ZF performance. Those comments I > >> receive > >> in my blog where I talk about ZF and even maybe promote it and in local > >> PHP > >> forum too. > >> OK - those who comment cant provide exact numbers in which I could see > >> difference between ZF and other frameworks. But all they need to say - ZF > >> is > >> complicated, big and with a lot of components etc. etc. And each version > >> is > >> becoming bigger and bigger. I would like to argue, that growth in > >> features > >> is not affecting speed > > > > But that's precisely true. Growth in breadth does not equal decrease in > > performance. On a typical request, you're using a very small subset of > > the available functionality -- and anything you're not using is _not_ > > loaded. The argument is basically a straw man. > > > >> - but I can't because there are no any tests out > >> there. > >> I hope you see the problem. In short "They say it is slow, but there is > >> no > >> way we can prove they are wrong". > > > > Another way to put is is, "they say it is slow, but have no numbers to > > back it up." Just depends what side of the argument you're on. > > > > Our plan is to publish our methodology so others can reproduce our > > results. > > > > That said, we'll _always_ be slower than projects like CodeIgniter -- > > that project, in particular, is built with a very light footprint. The > > downside is that you have less available at your disposal to speed up > > development. > > > > The primary trade-off with any framework is almost always developer time > > over processor time. > > > > > >> And sorry for my grammar and structure of sentences. English is not my > >> mothers tongue, so it is not very easy for me to write in correct > >> English. > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Speed-and-performance-between-ZF-releases-tp19164298p19167401.html > Sent from the Zend Framework mailing list archive at Nabble.com. > -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
