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-03 05:53:17 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.

I think that you are experiencing the problem that I was.... it
probably has to do with your hard drive setup as I described in the
other thread.

Lucky for you, the autoload patch I submitted to the 1.3 branch will
fix this right up. Alternatively, you can also patch the 1.2 release
version with this autoload patch, which I do myself. I posted the 1.2
patch to the other thread as well.

The autoload patch removes the 'inside-the-function-include' from the
generated classes to fix this exact problem.

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

As I said, you can write your own _once IFF you decide that you don't
mind losing the functionality that causes the core one to be slow
(that is, worrying that include_path has changed since the last time
you included the file and thus this time, you mean to include a
different file).

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

Try my patch...


> Cameron
> 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
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org