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 Cameron Brunner <cameron.brunner@gmail.com>
Full name Cameron Brunner <cameron.brunner@gmail.com>
Date 2006-10-02 22:51:24 PDT
Message My issue is with doSelectJoinBlah where blah is a parent table in a
one to many relationship and i am pulling upwards of 2000 records from
the child table. If i remove the require_once and put it at the top of
the php file its fast, if i dont it sits there for centuries reopening
the file over and over again. This problem is DEFINANTLY worse on my
64bit workstation compared to the 32bit servers i have sitting here
and it adds nearly a minute to a cron job that i run because of it.

As for my php info, this is a cron job that its mostly causing issues
with and currently iv tried latest php 5.1 in portage, php 5.1 from
cvs and 5.2 from cvs, all with/without xdebug/eaccel and have found it
to make basically no real difference.

require_once in autoload i would say is still required, what if a user
does something stupid like include the file themselves first before we
want it?

as for a custom _once, it needs to monitor include_path as well to
decide if the file is right or not which will negate most of the
performance boost it gives.

if you want some hard numbers i can get them out of it again, i just
threw up my hands when i realized what was wrong and decided that we
needed to do something about this when we are working with so many
objects and require_once's because of them.


On 10/2/06, Alan Pinstein <apinstein at mac dot com> wrote:
> 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