Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Alan Pinstein <apinstein@mac.com>
Full name Alan Pinstein <apinstein@mac.com>
Date 2006-10-01 09:18:14 PDT
Message 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!


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