Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] Propel 2.0 spl_autoload

propel
Discussion topic

Back to topic list

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot 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
>
>

« Previous message in topic | 22 of 40 | Next message in topic »

Messages

Show all messages in topic

Propel 2.0 spl_autoload Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2006-10-01 01:50:23 PDT
     Re: [propel-dev] Propel 2.0 spl_autoload hlellelid Hans Lellelid 2006-10-01 06:10:24 PDT
         Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 08:08:20 PDT
         Re: [propel-dev] Propel 2.0 spl_autoload Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2006-10-02 22:41:01 PDT
     Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-01 07:22:51 PDT
     Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 08:36:02 PDT
         Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-01 08:47:42 PDT
             Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 09:18:14 PDT
             Re: [propel-dev] Propel 2.0 spl_autoload Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2006-10-01 09:38:18 PDT
                 Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-01 09:50:26 PDT
                     Re: [propel-dev] Propel 2.0 spl_autoload Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2006-10-01 09:59:57 PDT
                         Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 10:40:56 PDT
                             Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-01 10:50:02 PDT
                                 Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 11:19:50 PDT
                                     Re: [propel-dev] Propel 2.0 spl_autoload Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2006-10-01 12:35:38 PDT
                                         Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 14:50:44 PDT
                                             Re: [propel-dev] Propel 2.0 spl_autoload Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2006-10-01 20:09:57 PDT
         Re: [propel-dev] Propel 2.0 spl_autoload Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2006-10-02 22:51:24 PDT
             Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-03 03:44:33 PDT
                 Re: [propel-dev] Propel 2.0 spl_autoload Soenke Ruempler <soenke at ruempler dot eu> Soenke Ruempler <soenke at ruempler dot eu> 2006-10-03 04:04:09 PDT
             Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-03 05:53:17 PDT
                 Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-03 06:11:27 PDT
                     Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-03 06:19:24 PDT
                 Re: [propel-dev] Propel 2.0 spl_autoload Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2006-10-03 07:30:28 PDT
                     Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-03 07:57:51 PDT
Page: of 2 « Previous | Next »
Messages per page: