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 =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Date 2006-10-03 06:11:27 PDT
Message Did you commit anything regarding autoload to the 1.3 branch yet,
Alan? I can't find any autoloading stuff in the core Propel files.

Am 03.10.2006 um 14:53 schrieb Alan Pinstein:

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