Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
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 08:36:02 PDT
Message Cameron-

I'd like to hear more about your require_once issues... are you using
an opcode cache?

I have a lot of experience in optimization, and something just isn't
smelling right about this _once stuff to me... I am not yet convinced
that we know what the problem is.

I posted a *huge* long message that I spent 3 hours researching the
other day, and not a single person responded to it... please go read
it and let me know your thoughts.

The message is in propel-dev:
> Subject: Re: [propel-dev] Re: [propel-bugs] Re: [Propel] #267:
> Change Propel to use PDO for runtime db abstraction
> Date: September 25, 2006 12:50:29 PM EDT

Basically, without using an opcode cache, I was unable to detect any
difference in include style (require/require_once/include/
include_once) on speed. I tested on multiple machines.

I have not tested with an opcode cache, but I'd love to see some
results. I'd do it myself now, but I don't have an appropriate
environment setup (php 5.1, latest APC). I don't want to switch to
5.1 presently, as I'm in the middle of some projects.

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.

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).

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.
- 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.

Looking forward to comments...

Alan


On Oct 1, 2006, at 4:50 AM, Cameron Brunner wrote:

> Any objections if i work on my own patch (and commit it once working)
> to allow spl_autoload() to be used and required? As in no more ability
> to disable the requirement of spl_autoload... The performance issues
> with require_once in my setup are just getting insane and i keep
> having to manually patch files every time i alter the database and
> rebuild the propel classes...
>
>
> Cameron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>