Hi all, I find the whole discussion interesting - please keep it up ;)
In my opinion, discussing adding autoloading at this stage rates as premature optimisation. As someone else noted, we're making educated opinions not backed by hard data. Where is the sample Zend Framework application showing both in operation with an XDebug cachegrind and a few simple measures like reqs/sec? It doesn't exist yet - so adding an autoload function is ill-advised at this time. The way I see it, autoloading is an optimisation. I know it can make requiring/including easier, but how much easier? The ZF has most things included in an intelligent fashion from the top-level common files like interfaces and abstracts - is it all that hard to find them? I don't think so...least I can't see it. Since I'm already working on two ZF applications the way I view it is that the use of autoload doesn't seen to offer many benefits (it might even add costs rather) when an opcode cache is available - there are enough statements and resolved bug reports around to point out an opcode cache, while not totally useless with autoload, does lose some of its effectiveness - whether that's measureable or not, well see my first paragraph. Implementing autoload so it's "easier" to include files if a penalty to opcode cache users exists doesn't strike me as a good idea. On the flipside, I also cater to a large contingent of shared host users who unquestionably would benefit from autoloading. However I don't view this as a huge ZF problem - getting an application packaged and online is up to the application developer, so just like Arnaud mentioned I'm using a build process to make use of both options. Using Phing, I can build a version with require_once() left as is (my preference for ZF to default to) and another with them stripped out and an autoload function implemented. All it takes is a command console, a phing command, a custom task class, and a few minutes while the source code is checked out, processed and packaged. This way I can shoot off a version for any shared host user, and an alternative for those with a dedicated server or any host which supports custom compiling PHP. That probably doesn't appeal to everyone - just pointing out some of us can push in autoloading as it is without much effort or debate if its warranted for some end users... Pádraic Brady http://blog.quantum-star.com http://www.patternsforphp.com P.S. Hope everyone had a great Christmas and New Year! ----- Original Message ---- From: titerm <[EMAIL PROTECTED]> To: fw-general@lists.zend.com Sent: Tuesday, January 9, 2007 10:24:19 PM Subject: Re: [fw-general] ZF and Autoloading IMHO, the main point of autoload is not to be faster or not. The point is not to have to maintain include directive. You are using a class, autoload will load it. After a while, you don't use it anymore, it won't be loaded anymore. That's it. I use APC for better performance, but i use also page caching and user data caching through APC user share memory. APC is a good thing, but it s not enough to take the best perfs from a heavily loaded server. Laurent Richard Thomas a écrit : > That doesn't even make common sense, autoload will never be faster > then straight require if the exact same number of files are called > each time, there is less overhead. > > The only way for them to get the below results would of been to > include every file in propel straight out even if it wasn't used which > is just stupid. > > File per file autoload is slower, If you know a file is going to be > needed without question you will get better performance if you require > it. > > The best solution is to find a middle ground, what files get called > 50%+ of the time in your application and preload those, let the rest > be autoloaded. > > This would give you the best of both worlds, performance and flexability. > > On 1/9/07, Cameron Brunner <[EMAIL PROTECTED]> wrote: >> These are tests that were done for Propel, note that propel has now >> gone to requiring spl_autoload because of these results. >> >> this is using eaccel as apc was crashing for him, php 5.0.4, october 4th >> >> (02:38:26) let's see if it crashes my apache like APC does >> (02:38:35) nope! >> (02:38:41) shit >> (02:38:44) it's like 3x faster >> (02:39:09) even w/o doing a huge list of require's >> (02:39:11) lemme test >> (02:41:03) ok >> (02:41:06) so with eacc >> (02:41:26) .25 req/sec with no accelerator (with or w/o require list) >> (02:41:30) with eacc >> (02:41:39) .55 req/sec w/autoload >> (02:41:45) .49 w/ list of requires >> >> the list of requires was literally just a list of >> require('filea'); >> require('fileb'); >> etc at the top of the script. Yes, require, not require_once. No i >> dont have how many files it was including here in my logs however >> propel includes a lot of files so it should be a reasonable >> comparison. >> >> Can we please finally come to a conclusion on this subject? Test for >> yourself or use these as a reference but PLEASE stop this FUD >> surrounding autoload! >> >> >> Cameron >> > > > __________ NOD32 1967 (20070109) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
