Ok, interesting... so you're saying the best thing to do then is to switch to full autoload, using require() inside of the autoload, and that should make propel opcocde-cache "compliant" (for lack of a better word)?

If so, then it sounds like we've got our solution!

BTW - I am gonna go try out some of this on my framework too... see if it speeds up with APC!

Alan

On Oct 1, 2006, at 11:47 AM, David Zülke wrote:

>> However, according to what I've read, the hit it *slight* and not >> *huge*. But how can I know until I see numbers that actually test >> the require_once part. This means setting up a bare-bones example >> without large code (as compiling time masks the true hit of the >> _once call). Or better yet, some profiling numbers of the same >> code running with require vs. require_once and looking at the >> results.>> Prior to 5.2 and the latest APC, _once calls were not accelerated > _at all_ by APC because there was no way for a cache to hook in.>>>> My worry is that people are starting to thing require_once is slow >> *in general* which it isn't. I believe that it is slower with >> opcode caches (although I don't see why, granted I haven't looked >> into it and I'm sure it's complicated).>> It is slower than a regular require. I recently threw out all but > one _once call from Agavi, and with APC (on 5.0.4), the page > rendering time dropped by 50(!) percent.>>>> I am concerned that wholesale replacement of _once with the non- >> _once versions is a bad idea. They are not logically equivalent on >> their face!>>>> Before we go and make such a change, I'd like to have a discussion >> about it.>>>> - One option suggested was that require_once inside of autoload is >> redundant; that since it's autoload you can be sure that you'll >> only load a file exactly once anyway, b/c once it's loaded autoload >> () won't get called again for that class or any other class in >> that file.>> Of course. Using _once inside an autoload is utterly stupid. Why > would you do that. It only gets called when the class was not found > anyway ;)>> I emailed the APC dev list during the discussion in the other > thread, and Rasmus said that while dynamic/conditional loads (e.g. > a require inside an if, or an autoload) are accelerated by APC, > too, there won't be the same amount of improvement over a straight > require(). I still believe that autoload is the better solution; > not only because it makes things cleaner, but also because it > offers the most fine-grained JIT-style loading you could possibly > have with next to no effort as opposed to require calls, where you > might end up loading more than you need in the specific situation.>>>> - Another option is to write your own require_once. I kinda did >> this for one of my projects, and it works. I think the reason >> require_once is goofy is that it handles a lot of situations that >> most code would not need to rely on. For instance, if one does >> "require_once 'a/b/c.php', and there are 5 directories in >> include_path, then technically there are 5 different solutions to >> that require_once. I am guessing maybe that a lot of the >> quirkiness of the _once calls is dealing with stuff like this. I >> wrote my own require once that implements the _once part simply by >> keeping track of whether or not that exact string has been >> included before, and if so, simply exits, and if not, calls the >> non-_once counterpart to require/include it. This seems to work >> functionally, and seems that also it might avoid the _once hit >> discussed on the opcode cache forums.>> We had some guys on #agavi who did that since APC prior to PHP 5.2 > would randomly produce errors about classes not found - turned out > the _once stuff was the problem.>>> David>> --------------------​--------------------​--------------------​---------> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org> For additional commands, e-mail: dev-help at propel dot tigris dot org>