They will be published on the framework site in a prominent location. Whether that is on the wiki or somewhere else has yet TBD. As for the timing, the scope, and the format of the tests/results, we are shooting for sometime within a few weeks after the 1.5 release, the scope would be broad and deep enough to be useful for optimization in both ZF and most applications (although we may or may not run other frameworks through the same benchmarks for comparison or tests against every component in ZF), and the format of the tests/results is entirely TBD (you can rest assured they will be designed to reveal any areas for improvement; we're not looking for transparency- not marketing materials- here). In addition, we hope to establish a reusable set of benchmarks and tests; everyone should be aware, however, that results can't be directly compared across different environments except WRT well defined variables such as whether an opcode cache was used or not. If anyone has any suggestion for specific scenarios or areas we should be testing, please post them to fw-general.
Also, I know that it has been mentioned before, but it's worth repeating. On the framework team we seek to strike the best balance between performance and ease of development and maintainability. If all applications were designed with only performance in mind, we would live in a very different technical world with far fewer innovations and a much longer time-to-market across almost all technical domains- web development would certainly be no exception. I believe most battle-scarred developers and architects would tell you that the most effective performance optimizations happen below the application programming level (witness all the query optimization and rewriting that happens in Oracle, for example; I can tell you that very few people know how to or invest the time to implement these optimization in their own queries and schemas) and that you reach the law of diminishing returns very quickly with the cost of developer time vs. additional hardware (hosting cost, etc.) nowadays. AFAIK, opcode caches are a perfect example of developer-transparent performance optimization. I hope that gives you some insight in to how we prioritize work for ZF; for Zend Framework it means that we will be busy in the next month delivering a lot of the features that our users have been asking for, and performance improvements that are exposed by benchmarks may have to wait for subsequent mini or minor releases after 1.5. That said, if anyone in the community has a great performance improvement that they can back up with benchmarks- especially if it is transparent to the developer- there is still time to get it in to 1.5! :) ,Wil > -----Original Message----- > From: Eric Coleman [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 15, 2007 10:00 PM > To: Wil Sinclair > Cc: Philip G; fw-general; fw-core > Subject: Re: [fw-core] RE: [fw-general] Reducing the number of loaded > exception files > > When and where will these results be published? > > Regards, > Eric > > On Dec 15, 2007, at 9:58 PM, Wil Sinclair wrote: > > > Hey guys, sorry I didn't get a chance to reply to this thread until > > now. > > While I might not be an expert on performance tuning in PHP, I > believe > > there are a few best practices that apply to all languages and > > frameworks out there. Foremost among these is never increase code > > complexity before having reasonable benchmarks to give you a decent > > 'before' and 'after' picture of the optimization. I realize that PHP > > is > > somewhat unique in the benefit it can realize from an opcode cache, > > so I > > would expect these figures for both opcode-cached and -uncached > > installations. I also realize the extent of the complexity that > > might be > > introduced- in fact, we might be able to simplify the lazy-loading of > > exception classes further by introducing a factory method- possibly > in > > the Zend_Loader class- which doesn't make for a whole hell of a lot > of > > complexity. That said, it does add SOME complexity to the framework, > > since we either have to include the exception class in more places > > than > > we had to previously or we would have to prescribe a different > > method of > > exception class loading than the most basic suggested usage at the > > language level, and is therefore subject to the rule of thumb I > > mention > > above. > > Fortunately, we plan to do a performance audit of framework in the > 1.5 > > timeframe that will create exactly these benchmarks to test against > > going forward. ;D While I imagine that these will support a strong > > argument for lazy loading of exceptions, I suggest we wait until > we've > > had a chance to run these benchmarks to decide which optimizations of > > the many possibilities that we agree are worth the extra complexity. > > Ultimately, this is another argument against 'premature > optimization', > > but I'm being slightly more specific about the definition of > > 'premature' > > here- anything before our 1.5 performance tests are executed and the > > results compiled. :) > > > > Thanks. > > ,Wil > > > >> -----Original Message----- > >> From: Philip G [mailto:[EMAIL PROTECTED] > >> Sent: Saturday, December 15, 2007 2:17 PM > >> To: fw-general; fw-core > >> Subject: Re: [fw-general] Reducing the number of loaded exception > > files > >> > >> On Dec 15, 2007 3:43 PM, Shahar Evron <[EMAIL PROTECTED]> wrote: > >>> Hi Nico, > >>> > >>> On Sat, 2007-12-15 at 16:54 +0100, Nico Edtinger wrote: > >>>> Shahar Evron wrote: > >>>>> 10 redundant include files have quite an impact on performance, > >>>>> especially in places where you have no opcode cache installed. > >>>> > >>>> If you don't have an opcode cache you simply don't care about > >>>> performance. So why should we optimize for these people? > >>> > >>> That's not true - some people (actually much more than "some") run > > in > >>> shared hosting environments where they have no control on what PHP > >>> extensions are installed. > >>> > >>> Also, IMHO we build a framework, and it should be used by *users* > > who > >>> *do not need to care* about much. The whole essence of frameworks > is > >>> like saying "I'll take care of this issue for you, so you don't > have > >> to > >>> care about that". > >>> > >> > >> As a user and developer, I'm going to have to agree with Shahar > here. > >> Majority of your users are going to be on shared servers where they > >> do > >> not have control of what caching, if any, is installed. A framework > >> that is meant to be used by users (think RoR) needs to be as > >> optimized > >> as possible by the original coders. Simply saying "use opcode > >> caching" > >> is a poor excuse for poorly developed code. > >> > >> This is just my opinion as a developer...btw, this message might not > >> make it to the fw-core list as I don't believe I'm on it. > >> > >> -- > >> Philip > >> [EMAIL PROTECTED] > >> http://www.gpcentre.net/
