Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Propel 2.0 spl_autoload

propel
Discussion topic

Hide all messages in topic

All messages in topic

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-10-04 12:47:32 PDT
Message Understood... Agreed and this is definitely a "light" version,
thank you Hans I've been waiting to hear that...

I won't fork it... I'll release this and help you guys however I can...

On 10/4/06, Hans Lellelid <hans at velum dot net> wrote:
> Ok, fair enough :)
>
> Yes, Pedram, I think we're all in agreement that you can do what you
> will with PHP4-Propel. I never heard back from Michael, but, assuming
> you also didn't hear anything, I'm guessing that he's ok with the old
> PHP4 version being licensed under a more liberal license. That said,
> the PHP4 version is a pretty big step backward in functionality.
>
> Hans
>
> David Zülke wrote:
> > Actually, my tone was a bit brusque, yes, and that's because you
> > offered SVN access for anyone who'd like to contribute to the PHP4
> > version about 7123617263 times, and yet, he doesn't seem to care, but
> > instead prefers to walk in, tells us why he thinks Propel is useless
> > and then acts all huffy with some "I'm forking Propel and do it
> > properly" instead of doing the obvious, namely fixing his complaints
> > himself. Also, I do not _at all_ understand why he complains about
> > Propel not being suitable for opcode caching in the very thread that
> > discusses the elimination of this drawback.
> >
> > So, Pedram, just drop Hans a line and he'll be happy to set up an SVN
> > account for you.
> >
> > David
> >
> >
> > Am 04.10.2006 um 14:33 schrieb Hans Lellelid:
> >
> >> Hi Pedram,
> >>
> >> David's tone may have been a bit brusque, but it's probably a cultural
> >> difference more than a personal one. In any event, he's right that
> >> we're not concerning ourselves with PHP4, not after PHP5 has been out
> >> for years. PHP4 may exist in legacy applications, but it is dead for
> >> new project development. PEAR is about to require all new packages be
> >> PHP5, which (given PEAR's relatively conservative outlook) is a pretty
> >> good indication that it is in its twilight.
> >>
> >> Also, I think you under-appreciate David, Alan, et. al research &
> >> contribution to the problem at hand. David isn't reporting hearsay
> >> about engine internals, he took the time to write to internals and find
> >> out why it was behaving as it is.
> >>
> >> Anyway, we are all enterprise programmers here. And I think this
> >> project is extremely open to contributions and suggestions. You are
> >> welcome to propose additions to the generator and/or runtime, and I'm
> >> confident that your ideas will get as much attention as anyone else's.
> >> Of course, you will be more likely to see your ideas adopted and code
> >> accepted, if you are able to work with others on the list in a
> >> constructive way.
> >>
> >> Hans
> >>
> >> Pedram Nimreezi wrote:
> >>> That's the thing... I don't load every class every request...
> >>> I'm loading the classes I'll know I'll need all the time...
> >>> And no David I don't think I'm solving yesterdays problems...
> >>> and I don't really appreciate your attitude either...
> >>> My web applications push what can be done on the net today
> >>> and I've been programming for 15 years... php 4 will be
> >>> dead in about 3 years... it's not dead yet... and net years
> >>> are like dog years.... I'm an enterprise programmer what
> >>> maybe great for everybody is buggy inconsistency for me...
> >>> Not everyone has the same stringent requirements yet
> >>> everyone is very quick to jump in to add what they've
> >>> "heard" .... Ignoring the fact that I have actual tests and
> >>> years of research already invested is what is utter frickin nonsense..
> >>>
> >>>
> >>> On 10/3/06, Soenke Ruempler <soenke at ruempler dot eu> wrote:
> >>>> On 03.10.2006 21:19, Pedram Nimreezi wrote:
> >>>>
> >>>>> I think I'm gonna fork propel and creole.... at least my version,
> >>>>> its designed for opcode caching and is backward compatible for 4
> >>>>> and 5
> >>>>> and I want to focus on the application writing, this is enough for
> >>>> db...
> >>>>> As for the performance issues I've fixed that quite a long time ago
> >>>>> and when I was discussing it no one would even acknowledge it...
> >>>>> and I don't use php 5 or APC... as they're both still buggy...
> >>>>> (even 2
> >>>>> years later)
> >>>>
> >>>> Yeah, APC is buggy for PHP 5. I'm using PHP 5.1 with eAccelerator
> >>>> 0.9.5
> >>>> - very stable! Maybe you wanna give it a try. PHP 4 is history in my
> >>>> eyes (and only bug fixed by some bigger companies that rely on it
> >>>> [say:
> >>>> eZ]).
> >>>>
> >>>> --
> >>>> Best regards / Mit freundlichen Gruessen
> >>>>
> >>>> Sönke Ruempler
> >>>> soenke at ruempler dot eu
> >>>> http://www.ruempler.eu/
> >>>>
> >>>> --------------------​--------------------​--------------------​---------
> >>>> 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
> >>
> >>
> >
> > --------------------​--------------------​--------------------​---------
> > 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
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-10-04 06:12:18 PDT
Message Ok, fair enough :)

Yes, Pedram, I think we're all in agreement that you can do what you
will with PHP4-Propel. I never heard back from Michael, but, assuming
you also didn't hear anything, I'm guessing that he's ok with the old
PHP4 version being licensed under a more liberal license. That said,
the PHP4 version is a pretty big step backward in functionality.

Hans

David Zülke wrote:
> Actually, my tone was a bit brusque, yes, and that's because you
> offered SVN access for anyone who'd like to contribute to the PHP4
> version about 7123617263 times, and yet, he doesn't seem to care, but
> instead prefers to walk in, tells us why he thinks Propel is useless
> and then acts all huffy with some "I'm forking Propel and do it
> properly" instead of doing the obvious, namely fixing his complaints
> himself. Also, I do not _at all_ understand why he complains about
> Propel not being suitable for opcode caching in the very thread that
> discusses the elimination of this drawback.
>
> So, Pedram, just drop Hans a line and he'll be happy to set up an SVN
> account for you.
>
> David
>
>
> Am 04.10.2006 um 14:33 schrieb Hans Lellelid:
>
>> Hi Pedram,
>>
>> David's tone may have been a bit brusque, but it's probably a cultural
>> difference more than a personal one. In any event, he's right that
>> we're not concerning ourselves with PHP4, not after PHP5 has been out
>> for years. PHP4 may exist in legacy applications, but it is dead for
>> new project development. PEAR is about to require all new packages be
>> PHP5, which (given PEAR's relatively conservative outlook) is a pretty
>> good indication that it is in its twilight.
>>
>> Also, I think you under-appreciate David, Alan, et. al research &
>> contribution to the problem at hand. David isn't reporting hearsay
>> about engine internals, he took the time to write to internals and find
>> out why it was behaving as it is.
>>
>> Anyway, we are all enterprise programmers here. And I think this
>> project is extremely open to contributions and suggestions. You are
>> welcome to propose additions to the generator and/or runtime, and I'm
>> confident that your ideas will get as much attention as anyone else's.
>> Of course, you will be more likely to see your ideas adopted and code
>> accepted, if you are able to work with others on the list in a
>> constructive way.
>>
>> Hans
>>
>> Pedram Nimreezi wrote:
>>> That's the thing... I don't load every class every request...
>>> I'm loading the classes I'll know I'll need all the time...
>>> And no David I don't think I'm solving yesterdays problems...
>>> and I don't really appreciate your attitude either...
>>> My web applications push what can be done on the net today
>>> and I've been programming for 15 years... php 4 will be
>>> dead in about 3 years... it's not dead yet... and net years
>>> are like dog years.... I'm an enterprise programmer what
>>> maybe great for everybody is buggy inconsistency for me...
>>> Not everyone has the same stringent requirements yet
>>> everyone is very quick to jump in to add what they've
>>> "heard" .... Ignoring the fact that I have actual tests and
>>> years of research already invested is what is utter frickin nonsense..
>>>
>>>
>>> On 10/3/06, Soenke Ruempler <soenke at ruempler dot eu> wrote:
>>>> On 03.10.2006 21:19, Pedram Nimreezi wrote:
>>>>
>>>>> I think I'm gonna fork propel and creole.... at least my version,
>>>>> its designed for opcode caching and is backward compatible for 4
>>>>> and 5
>>>>> and I want to focus on the application writing, this is enough for
>>>> db...
>>>>> As for the performance issues I've fixed that quite a long time ago
>>>>> and when I was discussing it no one would even acknowledge it...
>>>>> and I don't use php 5 or APC... as they're both still buggy...
>>>>> (even 2
>>>>> years later)
>>>>
>>>> Yeah, APC is buggy for PHP 5. I'm using PHP 5.1 with eAccelerator
>>>> 0.9.5
>>>> - very stable! Maybe you wanna give it a try. PHP 4 is history in my
>>>> eyes (and only bug fixed by some bigger companies that rely on it
>>>> [say:
>>>> eZ]).
>>>>
>>>> --
>>>> Best regards / Mit freundlichen Gruessen
>>>>
>>>> Sönke Ruempler
>>>> soenke at ruempler dot eu
>>>> http://www.ruempler.eu/
>>>>
>>>> --------------------​--------------------​--------------------​---------
>>>> 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
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

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-04 06:04:48 PDT
Message Actually, my tone was a bit brusque, yes, and that's because you
offered SVN access for anyone who'd like to contribute to the PHP4
version about 7123617263 times, and yet, he doesn't seem to care, but
instead prefers to walk in, tells us why he thinks Propel is useless
and then acts all huffy with some "I'm forking Propel and do it
properly" instead of doing the obvious, namely fixing his complaints
himself. Also, I do not _at all_ understand why he complains about
Propel not being suitable for opcode caching in the very thread that
discusses the elimination of this drawback.

So, Pedram, just drop Hans a line and he'll be happy to set up an SVN
account for you.

David


Am 04.10.2006 um 14:33 schrieb Hans Lellelid:

> Hi Pedram,
>
> David's tone may have been a bit brusque, but it's probably a cultural
> difference more than a personal one. In any event, he's right that
> we're not concerning ourselves with PHP4, not after PHP5 has been out
> for years. PHP4 may exist in legacy applications, but it is dead for
> new project development. PEAR is about to require all new packages be
> PHP5, which (given PEAR's relatively conservative outlook) is a pretty
> good indication that it is in its twilight.
>
> Also, I think you under-appreciate David, Alan, et. al research &
> contribution to the problem at hand. David isn't reporting hearsay
> about engine internals, he took the time to write to internals and
> find
> out why it was behaving as it is.
>
> Anyway, we are all enterprise programmers here. And I think this
> project is extremely open to contributions and suggestions. You are
> welcome to propose additions to the generator and/or runtime, and I'm
> confident that your ideas will get as much attention as anyone else's.
> Of course, you will be more likely to see your ideas adopted and code
> accepted, if you are able to work with others on the list in a
> constructive way.
>
> Hans
>
> Pedram Nimreezi wrote:
>> That's the thing... I don't load every class every request...
>> I'm loading the classes I'll know I'll need all the time...
>> And no David I don't think I'm solving yesterdays problems...
>> and I don't really appreciate your attitude either...
>> My web applications push what can be done on the net today
>> and I've been programming for 15 years... php 4 will be
>> dead in about 3 years... it's not dead yet... and net years
>> are like dog years.... I'm an enterprise programmer what
>> maybe great for everybody is buggy inconsistency for me...
>> Not everyone has the same stringent requirements yet
>> everyone is very quick to jump in to add what they've
>> "heard" .... Ignoring the fact that I have actual tests and
>> years of research already invested is what is utter frickin
>> nonsense..
>>
>>
>> On 10/3/06, Soenke Ruempler <soenke at ruempler dot eu> wrote:
>>> On 03.10.2006 21:19, Pedram Nimreezi wrote:
>>>
>>>> I think I'm gonna fork propel and creole.... at least my version,
>>>> its designed for opcode caching and is backward compatible for 4
>>>> and 5
>>>> and I want to focus on the application writing, this is enough for
>>> db...
>>>> As for the performance issues I've fixed that quite a long time ago
>>>> and when I was discussing it no one would even acknowledge it...
>>>> and I don't use php 5 or APC... as they're both still buggy...
>>>> (even 2
>>>> years later)
>>>
>>> Yeah, APC is buggy for PHP 5. I'm using PHP 5.1 with eAccelerator
>>> 0.9.5
>>> - very stable! Maybe you wanna give it a try. PHP 4 is history in my
>>> eyes (and only bug fixed by some bigger companies that rely on it
>>> [say:
>>> eZ]).
>>>
>>> --
>>>
>>> Best regards / Mit freundlichen Gruessen
>>>
>>> Sönke Ruempler
>>> soenke at ruempler dot eu
>>> http://www.ruempler.eu/
>>>
>>> --------------------​--------------------​--------------------​--------
>>> -
>>> 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
>
>

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-10-04 05:33:00 PDT
Message Hi Pedram,

David's tone may have been a bit brusque, but it's probably a cultural
difference more than a personal one. In any event, he's right that
we're not concerning ourselves with PHP4, not after PHP5 has been out
for years. PHP4 may exist in legacy applications, but it is dead for
new project development. PEAR is about to require all new packages be
PHP5, which (given PEAR's relatively conservative outlook) is a pretty
good indication that it is in its twilight.

Also, I think you under-appreciate David, Alan, et. al research &
contribution to the problem at hand. David isn't reporting hearsay
about engine internals, he took the time to write to internals and find
out why it was behaving as it is.

Anyway, we are all enterprise programmers here. And I think this
project is extremely open to contributions and suggestions. You are
welcome to propose additions to the generator and/or runtime, and I'm
confident that your ideas will get as much attention as anyone else's.
Of course, you will be more likely to see your ideas adopted and code
accepted, if you are able to work with others on the list in a
constructive way.

Hans

Pedram Nimreezi wrote:
> That's the thing... I don't load every class every request...
> I'm loading the classes I'll know I'll need all the time...
> And no David I don't think I'm solving yesterdays problems...
> and I don't really appreciate your attitude either...
> My web applications push what can be done on the net today
> and I've been programming for 15 years... php 4 will be
> dead in about 3 years... it's not dead yet... and net years
> are like dog years.... I'm an enterprise programmer what
> maybe great for everybody is buggy inconsistency for me...
> Not everyone has the same stringent requirements yet
> everyone is very quick to jump in to add what they've
> "heard" .... Ignoring the fact that I have actual tests and
> years of research already invested is what is utter frickin nonsense..
>
>
> On 10/3/06, Soenke Ruempler <soenke at ruempler dot eu> wrote:
>> On 03.10.2006 21:19, Pedram Nimreezi wrote:
>>
>> > I think I'm gonna fork propel and creole.... at least my version,
>> > its designed for opcode caching and is backward compatible for 4 and 5
>> > and I want to focus on the application writing, this is enough for
>> db...
>> > As for the performance issues I've fixed that quite a long time ago
>> > and when I was discussing it no one would even acknowledge it...
>> > and I don't use php 5 or APC... as they're both still buggy... (even 2
>> > years later)
>>
>> Yeah, APC is buggy for PHP 5. I'm using PHP 5.1 with eAccelerator 0.9.5
>> - very stable! Maybe you wanna give it a try. PHP 4 is history in my
>> eyes (and only bug fixed by some bigger companies that rely on it [say:
>> eZ]).
>>
>> --
>>
>> Best regards / Mit freundlichen Gruessen
>>
>> Sönke Ruempler
>> soenke at ruempler dot eu
>> http://www.ruempler.eu/
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
>

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-10-03 20:15:20 PDT
Message That's the thing... I don't load every class every request...
I'm loading the classes I'll know I'll need all the time...
And no David I don't think I'm solving yesterdays problems...
and I don't really appreciate your attitude either...
My web applications push what can be done on the net today
and I've been programming for 15 years... php 4 will be
dead in about 3 years... it's not dead yet... and net years
are like dog years.... I'm an enterprise programmer what
maybe great for everybody is buggy inconsistency for me...
Not everyone has the same stringent requirements yet
everyone is very quick to jump in to add what they've
"heard" .... Ignoring the fact that I have actual tests and
years of research already invested is what is utter frickin nonsense..


On 10/3/06, Soenke Ruempler <soenke at ruempler dot eu> wrote:
> On 03.10.2006 21:19, Pedram Nimreezi wrote:
>
> > I think I'm gonna fork propel and creole.... at least my version,
> > its designed for opcode caching and is backward compatible for 4 and 5
> > and I want to focus on the application writing, this is enough for db...
> > As for the performance issues I've fixed that quite a long time ago
> > and when I was discussing it no one would even acknowledge it...
> > and I don't use php 5 or APC... as they're both still buggy... (even 2
> > years later)
>
> Yeah, APC is buggy for PHP 5. I'm using PHP 5.1 with eAccelerator 0.9.5
> - very stable! Maybe you wanna give it a try. PHP 4 is history in my
> eyes (and only bug fixed by some bigger companies that rely on it [say:
> eZ]).
>
> --
>
> Best regards / Mit freundlichen Gruessen
>
> Sönke Ruempler
> soenke at ruempler dot eu
> http://www.ruempler.eu/
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Soenke Ruempler <soenke at ruempler dot eu>
Full name Soenke Ruempler <soenke at ruempler dot eu>
Date 2006-10-03 15:07:25 PDT
Message On 03.10.2006 21:19, Pedram Nimreezi wrote:

> I think I'm gonna fork propel and creole.... at least my version,
> its designed for opcode caching and is backward compatible for 4 and 5
> and I want to focus on the application writing, this is enough for db...
> As for the performance issues I've fixed that quite a long time ago
> and when I was discussing it no one would even acknowledge it...
> and I don't use php 5 or APC... as they're both still buggy... (even 2
> years later)

Yeah, APC is buggy for PHP 5. I'm using PHP 5.1 with eAccelerator 0.9.5
- very stable! Maybe you wanna give it a try. PHP 4 is history in my
eyes (and only bug fixed by some bigger companies that rely on it [say:
eZ]).

--

Best regards / Mit freundlichen Gruessen

Sönke Ruempler
soenke at ruempler dot eu
http://www.ruempler.eu/

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 14:12:28 PDT
Message > Even with an opcode cache you have to respect the sandbox-principle of
> PHP. The Class/Function/Object-model is built upon every new request.
> Opcode Caches just eliminate parsing and compiling, but every
> class/function must be registered in the engine though.
>
> So I'm wondering if there are performance improvements or even losings
> in a big object model with one big file. Maybe (IMHO) just using (and
> registering) the classes that will be needed is faster!

That is correct. I doubt that a single-file approach would be able to
outperform an autoloading architecture considerably under typical
usage situations.

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Soenke Ruempler <soenke at ruempler dot eu>
Full name Soenke Ruempler <soenke at ruempler dot eu>
Date 2006-10-03 14:05:28 PDT
Message On 03.10.2006 21:50, Scott Wehrenberg wrote:

> On 10/3/06, Hans Lellelid <hans at velum dot net> wrote:
>> Another option would be to write a Phing task that builds all dependency
>> classes into a single file. This doesn't seem that difficult -- and
>> it's what Phing is great at. Then users can "build out" their Propel
>> package for performance reasons if they want to have everything packaged
>> in a single file. I don't see why this would be incompatible with other
>> ideas proposed.
>>
>
> I would love to see some speed comparisons between the single big file
> approach and the autoload method that's being worked on now. I'm
> guessing that the single big file would lose out without an opcache
> except in the rare circumstance where you're working with basically
> all of the classes for a request. It'd be a little more interesting to
> see how each did with the opcache.


Even with an opcode cache you have to respect the sandbox-principle of
PHP. The Class/Function/Object-model is built upon every new request.
Opcode Caches just eliminate parsing and compiling, but every
class/function must be registered in the engine though.

So I'm wondering if there are performance improvements or even losings
in a big object model with one big file. Maybe (IMHO) just using (and
registering) the classes that will be needed is faster!

-soenke

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Scott Wehrenberg <swehren at gmail dot com>
Full name Scott Wehrenberg <swehren at gmail dot com>
Date 2006-10-03 12:50:16 PDT
Message On 10/3/06, Hans Lellelid <hans at velum dot net> wrote:
>
> Another option would be to write a Phing task that builds all dependency
> classes into a single file. This doesn't seem that difficult -- and
> it's what Phing is great at. Then users can "build out" their Propel
> package for performance reasons if they want to have everything packaged
> in a single file. I don't see why this would be incompatible with other
> ideas proposed.
>

I would love to see some speed comparisons between the single big file
approach and the autoload method that's being worked on now. I'm
guessing that the single big file would lose out without an opcache
except in the rare circumstance where you're working with basically
all of the classes for a request. It'd be a little more interesting to
see how each did with the opcache.

--------------------​----------------
Scott Wehrenberg

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-10-03 12:47:04 PDT
Message Hi Pedram,

Pedram Nimreezi wrote:
> I think I'm gonna fork propel and creole.... at least my version,
> its designed for opcode caching and is backward compatible for 4 and 5
> and I want to focus on the application writing, this is enough for db...
> As for the performance issues I've fixed that quite a long time ago
> and when I was discussing it no one would even acknowledge it...
> and I don't use php 5 or APC... as they're both still buggy... (even 2
> years later)

Of course you are welcome to fork -- that's the great thing about
open-source software (though I'd say that it's a fairly small part of
the benefit).

Another option would be to write a Phing task that builds all dependency
classes into a single file. This doesn't seem that difficult -- and
it's what Phing is great at. Then users can "build out" their Propel
package for performance reasons if they want to have everything packaged
in a single file. I don't see why this would be incompatible with other
ideas proposed.

Hans

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 12:31:40 PDT
Message You're always welcome to contribute. If you're not interested in
that, enjoy the fork and have fun dealing with yesterday's problems.
There are times when you have to move on. Saying that PHP5 is "still"
buggy, even after two years, is utter nonsense, and you know that.


David



Am 03.10.2006 um 21:19 schrieb Pedram Nimreezi:

> I think I'm gonna fork propel and creole.... at least my version,
> its designed for opcode caching and is backward compatible for 4 and 5
> and I want to focus on the application writing, this is enough for
> db...
> As for the performance issues I've fixed that quite a long time ago
> and when I was discussing it no one would even acknowledge it...
> and I don't use php 5 or APC... as they're both still buggy... (even 2
> years later)
>
>
>
>
>
> On 10/3/06, Hans Lellelid <hans at velum dot net> wrote:
>> Hi -
>> >>> 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.
>> >>
>> >> *shoots 1.x* die already! :)
>> >
>> > Heh... well you should be prepared to wait a while on 2.0... 1.3
>> is up
>> > first and lays the groundwork for a lot of 2.0 stuff. I bet 2.0 is
>> > 4-6+ months away. Plus it's gonna be really unstable for a while
>> I'd
>> > think...
>> >
>>
>> Yes, except 2.0 to be very unstable for some time. I've got some
>> preliminary code from Ants for the Criteria2 work that he'd done.
>> I'm
>> going to look through that and see how to go about wiring that into
>> Propel, what needs work still, etc. So, Propel trunk will break any
>> backwards compatibility -- even with the existing trunk code. We've
>> been saying that for awhile. That's why it's not released ;)
>>
>> Hans
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
>
> --
> ~
> Pedram Nimreezi -- President/Senior Engineer
> Major Computing, Inc
> --
>
> Not by age, but by knowledge is wisdom acquired.
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-10-03 12:19:32 PDT
Message I think I'm gonna fork propel and creole.... at least my version,
its designed for opcode caching and is backward compatible for 4 and 5
and I want to focus on the application writing, this is enough for db...
As for the performance issues I've fixed that quite a long time ago
and when I was discussing it no one would even acknowledge it...
and I don't use php 5 or APC... as they're both still buggy... (even 2
years later)





On 10/3/06, Hans Lellelid <hans at velum dot net> wrote:
> Hi -
> >>> 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.
> >>
> >> *shoots 1.x* die already! :)
> >
> > Heh... well you should be prepared to wait a while on 2.0... 1.3 is up
> > first and lays the groundwork for a lot of 2.0 stuff. I bet 2.0 is
> > 4-6+ months away. Plus it's gonna be really unstable for a while I'd
> > think...
> >
>
> Yes, except 2.0 to be very unstable for some time. I've got some
> preliminary code from Ants for the Criteria2 work that he'd done. I'm
> going to look through that and see how to go about wiring that into
> Propel, what needs work still, etc. So, Propel trunk will break any
> backwards compatibility -- even with the existing trunk code. We've
> been saying that for awhile. That's why it's not released ;)
>
> Hans
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-10-03 10:47:11 PDT
Message Hi -
>>> 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.
>>
>> *shoots 1.x* die already! :)
>
> Heh... well you should be prepared to wait a while on 2.0... 1.3 is up
> first and lays the groundwork for a lot of 2.0 stuff. I bet 2.0 is
> 4-6+ months away. Plus it's gonna be really unstable for a while I'd
> think...
>

Yes, except 2.0 to be very unstable for some time. I've got some
preliminary code from Ants for the Criteria2 work that he'd done. I'm
going to look through that and see how to go about wiring that into
Propel, what needs work still, etc. So, Propel trunk will break any
backwards compatibility -- even with the existing trunk code. We've
been saying that for awhile. That's why it's not released ;)

Hans

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-10-03 08:23:53 PDT
Message I'm not arguing to the instability nor the missing features, its just
what im using and I like it and until recently 1.x required creole and
i didnt want that as a dependancy on my code.


Cameron

On 10/4/06, David Zülke <dz at bitxtender dot com> wrote:
> > Heh... well you should be prepared to wait a while on 2.0... 1.3 is
> > up first and lays the groundwork for a lot of 2.0 stuff. I bet 2.0
> > is 4-6+ months away. Plus it's gonna be really unstable for a while
> > I'd think...
>
> I agree. There's plenty of stuff on the agenda. Iterators for result
> sets, new Criteria, maybe better multi-database support, schema
> deltas, migrations, cross-referencing schemas etc. Also, it might be
> a good idea to wait for PHP6 _should_ it add namespaces support.
>
>
> David

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 08:12:02 PDT
Message > Heh... well you should be prepared to wait a while on 2.0... 1.3 is
> up first and lays the groundwork for a lot of 2.0 stuff. I bet 2.0
> is 4-6+ months away. Plus it's gonna be really unstable for a while
> I'd think...

I agree. There's plenty of stuff on the agenda. Iterators for result
sets, new Criteria, maybe better multi-database support, schema
deltas, migrations, cross-referencing schemas etc. Also, it might be
a good idea to wait for PHP6 _should_ it add namespaces support.


David

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-10-03 07:57:51 PDT
Message > I use 2.0 so patches for 1.2/3... hence why i want to do this
> properly in 2.0

Oh, well, you can try my patches on the 2.0 branch, but I don't know
if they'll work. I haven't merged into that yet.

I was thinking that we'd do the "official" merge once David and I are
done with all the patches for 1.3...

>> 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.
>
> XFS filesystem, running local on the server or via nfs (default way
> for all the servers since i need an easy realtime mirror for them)

Ok, well, I don't know whether it's the FS or the HD that matters...
for me, I can only compare HFS+ on IDE to EXT3 on SCSI RAID. I'd
assume that it's possible that XFS on IDE would be very slow too.

>> 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.
>
> *shoots 1.x* die already! :)

Heh... well you should be prepared to wait a while on 2.0... 1.3 is
up first and lays the groundwork for a lot of 2.0 stuff. I bet 2.0 is
4-6+ months away. Plus it's gonna be really unstable for a while I'd
think...

Why can't you use 1.3? or even a patched 1.2?

Alan

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-10-03 07:30:28 PDT
Message I use 2.0 so patches for 1.2/3... hence why i want to do this properly in 2.0

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

XFS filesystem, running local on the server or via nfs (default way
for all the servers since i need an easy realtime mirror for them)

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

*shoots 1.x* die already! :)

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

OK, well im working with you offlist to do 2.0's includes optimally so
we'll work thru it there.

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

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-10-03 06:19:24 PDT
Message Yes, I sure did.

I didn't change the core propel files very much... at the time of the
patch I was mostly concerned with autoloading the generated classes,
and felt that one of the core devs would be able to more quickly/more
correctly set up autoloading for the core files. All of the "embedded
includes" made me think I was gonna break something if I tried to fix
it, and I didn't want to get into it.

The only "core" includes now done in autoload are the "core" includes
that were in the generated classes.

Here's my patch / diff so you can see what all I touched. Basically I
fixed all of the generated classes and none of the core.
Attachments

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

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot 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...

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
>

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Soenke Ruempler <soenke at ruempler dot eu>
Full name Soenke Ruempler <soenke at ruempler dot eu>
Date 2006-10-03 04:04:09 PDT
Message On 03.10.2006 12:44, David Zülke wrote:

>> 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?
>
> then the autoload won't be called for that class becauase it's
> declared already. trust me, require() in the autoload function is
> enough.

One important point is that we need proper class prefixes of all Propel
2.0 classes/modules.

--

Best regards / Mit freundlichen Gruessen

Sönke Ruempler
soenke at ruempler dot eu
http://www.ruempler.eu/

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 03:44:33 PDT
Message > 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?

then the autoload won't be called for that class becauase it's
declared already. trust me, require() in the autoload function is
enough.

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot 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.


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

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-10-02 22:41:01 PDT
Message Sorry if i sounded rather blunt in that message but there hasnt been
much work done on 2.0 for a while and im starting to hit some
performance related issues so i wanted to make sure if i jumped in the
deep end that i wouldnt make a mess of something someone else is
doing. I'm just going thru all these emails now and will work out what
i plan to do about it shortly.


Cameron

On 10/1/06, Hans Lellelid <hans at velum dot net> wrote:
> I would say that this effort should be coordinated with Alan. I think
> there already is an autoload patch in 1.3 (Alan?) -- and if not, I know
> that there is an implementation plan. Certainly no one is stopping you
> from proposing your own approach to autoload, but since there are people
> actively working/thinking on this issue, it's probably best to
> coordinate rather than simply committing code.
>
> Thanks-
> Hans
>
> 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

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-10-01 20:09:57 PDT
Message for ajax and other asynchronous low latency requests theres a mark improvement.
With opcode caching (eaccelerator/apc) I get about 110 and without I
get about 55...
that was when i last bench marked, my framework has an abstraction for
the session
handler, when I switch from CreoleSession to MemcacheSession I can get some
requests to over 50% faster execution. There's also a difference in a scenario
where you want the session to always have the "latest" data, for
instance if it was
shifted by a foreign process (like an auction bid) or something less
real-time...
I go for real-time... I've demonstrated this with my web based IRC chat which
is pretty close to real-time and uses no plugins or outmoded polling methods.
Difference between the ajax and comet systems I have is that with Ajax the
requests are asynchronously made and its a retrieve and terminate connection,
with Comet the connection is never closed and a PHP output buffering flushing
technique does the incremental updates (with js) so that the server
can cause events to
fire on the browser side at the servers command. for instance (user
enters channel)
or (sysop requests your permission to send you a video clip)... these
are all the
sectors of web application design that are emerging and are seriously lacking
in discussion or accepted technique.... I'd love to commit my work for
consumption...
Including the realtime irc web chat which I can also open source that
uses little
dhtml in browser windows and utlizes the Smart_IRC lib from pear..
(its one of the good ones) btw I have this connection layer also implemented in
PECL so that it can handle much much higher scalability...

ps.. when part of the structure needs to be faster... you make it in c/c++...
in most cases its not needed but knowing when and not avoiding the right
implementation because its "hard" isnt correct attitude, I'd love to see a
full propel PECL so that I can have all the code I need (for
framework/maintainability)
but already built into PHP so theres not such a speed loss coming out
the gate...

that's my two cents... feel free to refund ;-)


On 10/1/06, Alan Pinstein <apinstein at mac dot com> wrote:
> So you have one HUGE file... how is performance? With opcode cache?
> Without? Because it's a serious consideration to shift to "requiring
> opcode cache" for propel...
>
> Alan
>
> On Oct 1, 2006, at 3:35 PM, Pedram Nimreezi wrote:
>
> > Alan you are expertly describing a problem that unfortunately
> > I did spend an unordinate waste of time turning a viable solution
> > out of..
> > that I believe are up to everyones standards, its a big damn file yes,
> > but there are very clean ways of working with it, attached is a
> > screenshot,
> > another example like the Widget one you described is the
> > Connection.php
> > plugin files for the various database abstractions, (I left those
> > things plugins)
> > without _once's, In fact the loading of those plugins based on the
> > type of
> > database you are accessing is an example of a conditional inclusion
> > which
> > is in this case an example of you may not be able to take ALL of
> > them out,
> > but 99% is still a very good accomplishment... attached is a
> > screenshot
> > of VIM, each class is collapsable and editing is very fast, and
> > this file
> > needs only to be included... my framework allows you to create
> > systems, controllers and actions that are EASY to work with they are
> > basically directories, objects and methods and evoke an organizing
> > trait
> > that is hard to find... especially by procedural programmers or
> > people who
> > make programs they hate to maintain...
> >
> >
> > On 10/1/06, Alan Pinstein <apinstein at mac dot com> wrote:
> >> Ok, right... so that is pretty much confirmation of what I had read
> >> previously... however, it doesn't help SOLVE the problem for large
> >> code libraries.
> >>
> >> Should we move over entirely to "compile-time" "require" statements
> >> in Propel? This would likely slow down things *a lot* without an
> >> opcode cache as we'd have to "require" all of the generated classes
> >> whether or not they're used. And I suppose it would speed them up
> >> with the cache, but who knows? Maybe the overhead of including lots
> >> of things you DON'T use would outweigh the gains from using a cache?
> >>
> >> Or do we chunk Propel into functional bits? Make people "require" any
> >> class they plan on using in a particular script?
> >>
> >> Other ideas?
> >>
> >> Alan
> >>
> >> On Oct 1, 2006, at 1:50 PM, David Zülke wrote:
> >>
> >> > http://news.php.net/​php.apc.dev/8
> >> > http://news.php.net/​php.apc.dev/9
> >> >
> >> >
> >> >
> >> > Am 01.10.2006 um 19:40 schrieb Alan Pinstein:
> >> >
> >> >> Pedram-
> >> >>
> >> >> Thanks for the post of your chat with Rasmus...
> >> >>
> >> >> I feel the need for speed too. I also have my own framework, and
> >> >> thus all of this include/autoload/_once stuff is very important to
> >> >> me. We aren't using it in such high-traffic situations now, but we
> >> >> are starting to use it on busier sites and I certainly don't want
> >> >> to hit a wall.
> >> >>
> >> >> It sounds like autoload and _once are bad for opcode caches. Fine.
> >> >> But we need a viable alternative. Turning every framework or
> >> >> library into a "single file" seems like an inordinate waste of
> >> >> time to me, and awfully un-clean. It just feels dirty to have to
> >> >> go through such gyrations to get performant code.
> >> >>
> >> >> I found this thread on the issue:
> >> >>
> >> >> http://pecl.php.net/​bugs/bug.php?id=6503​
> >> >>
> >> >> I am trying to figure out if in the FUTURE that autoload/
> >> >> require_once will not impact performance adversely.
> >> >>
> >> >> ----------------
> >> >>
> >> >> If in the future, autoload/require_once will continue to be slow
> >> >> in opcode-cache situations, then what is the solution?
> >> >>
> >> >> - Does that mean we need to have aggressive including? The
> >> >> Propel.php file would then include *tons* of files so that it can
> >> >> be cached properly w/o autoload?
> >> >> - How would we make sure that things don't happen 2x if we don't
> >> >> use _once? Maybe use autoload only to load Propel.php thus
> >> >> preventing the issue and minimizing autoload use? Is that enough?
> >> >> Does that even work?
> >> >>
> >> >> I think that frameworks and libraries are very important to good
> >> >> web coding. Yes, I could build a complex application using nothing
> >> >> but procedural PHP but come on, it wouldn't be very maintainable.
> >> >> It also makes it very hard to share code and libraries if there is
> >> >> no reasonable including/packaging mechanism.
> >> >>
> >> >> I have just read a bunch of stuff by Rasmus on the issue, and his
> >> >> overriding point is:
> >> >>
> >> >>> Use only include/require. If you know what you are including and
> >> >>> when, you shouldn't ever need to use include_once/require_once.
> >> >>> Do not use conditional includes. Do not use autoload.
> >> >>> [ paraphrasing ]
> >> >>
> >> >> So in practice, for a large code library, is this practical? I am
> >> >> just now starting to think about this, so forgive me if there is
> >> >> an obvious answer...
> >> >>
> >> >> Let's take a simple example from my framework. I have a bunch of
> >> >> "WFWidget" subclasses that implement all conceivable types of UI
> >> >> objects. Let's say there's around 30. How am I suppose to use only
> >> >> require, without require'ing all 30 files on every request,
> >> >> without using autoloads or conditional require's? I cannot
> >> >> conceive of a way, I suppose, other than having a large list of
> >> >> "require" calls at the top level of my "main php page". I suppose
> >> >> this could be done, but what a hassle! To have to include 30-40
> >> >> files each time I create a new web page! Ugh. Even if I chunk it
> >> >> into "WFFrameworkBase.php", "WFWidgets.php", then you still end up
> >> >> including lots of files you DON'T need!
> >> >>
> >> >> I am actually starting to worry very much about the viability of
> >> >> PHP if using frameworks on high-volume servers isn't going to have
> >> >> decent performance....
> >> >>
> >> >> Is it just me, or is there no good answer to this issue [if the
> >> >> PHP / APC devs don't figure out a way around the performance hit
> >> >> of autoload/_once]?
> >> >>
> >> >> Where are the best practices for doing this? I just seems crazy to
> >> >> me that we are struggling with the issue of how to write INCLUDE
> >> >> statements that doesn't cause terrible performance. What a waste
> >> >> of time. :(
> >> >>
> >> >> Alan
> >> >>
> >> >>
> >> >> On Oct 1, 2006, at 12:59 PM, Pedram Nimreezi wrote:
> >> >>
> >> >>> Sorry for the misunderstanding, I was saying Mojavi 3 is too
> >> >>> slow for me right now and anything on top of that is even more
> >> so,
> >> >>>
> >> >>> And I've used mojavi 1 and 2... it didn't get slow until 3... and
> >> >>> its not
> >> >>> even that its slow, its just you don't write php the way you
> >> >>> write java....
> >> >>>
> >> >>> there are many many tricks that if not employed will heavily
> >> >>> affect perf....
> >> >>>
> >> >>> but this is all based on perspective... I drive a 350z, to me a
> >> >>> "regular" car
> >> >>> is dipped in slow... some people think like me, some people
> >> >>> don't... and
> >> >>> Sean and I have disagreed face to face but I believe if he was
> >> >>> super happy
> >> >>> with the performance he would not of designed redline... which is
> >> >>> featherweight,
> >> >>> and just as usable for application design, in fact it runs faster
> >> >>> and
> >> >>> you learn it
> >> >>> faster so I would say everything is faster in general... but
> >> compare
> >> >>> it to Mojavi 3
> >> >>> or Agavi... anyway this was not the aspect of my post I even
> >> felt
> >> >>> like discussing...
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> On 10/1/06, David Zülke <dz at bitxtender dot com> wrote:
> >> >>>> > I was around for the start of Mojavi which is now kind of
> >> >>>> > Symfony/Agavi... this approach is almost academic and
> >> suffers a
> >> >>>> > significant performance run down in my experience when fully
> >> >>>> loaded
> >> >>>> > and are from what I've seen extra layers of bloat
> >> >>>> > added onto the fine work of Sean Kerr, my good friend...
> >> (mojavi
> >> >>>> > author)
> >> >>>>
> >> >>>> Funny you say that, because Sean doesn't think that way about
> >> >>>> Agavi.
> >> >>>> Have a look at it (trunk, not the latest stable version) to see
> >> >>>> what
> >> >>>> common problems it solves. There's a lot of stuff other
> >> frameworks
> >> >>>> just don't have an answer to. In general, most people
> >> familiar with
> >> >>>> it (and I guess I don't have to remind you that, in order to be
> >> >>>> able
> >> >>>> to make an educated decision about something, you have to be
> >> >>>> familiar
> >> >>>> with it) agree that the cleanliness, reusability and
> >> structure it
> >> >>>> offers by dar outweigh a possible performance decrease (rest
> >> >>>> assured
> >> >>>> that it is still fast enough and, most importantly, only
> >> marginally
> >> >>>> slower than Mojavi3, if any).
> >> >>>>
> >> >>>> David
> >> >>>>
> >> >>>>
> >> >>>>
> >> --------------------​--------------------​--------------------​-------
> >> >>>> --
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> >> >>>> For additional commands, e-mail: dev-help at propel dot tigris dot org
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> ~
> >> >>> Pedram Nimreezi -- President/Senior Engineer
> >> >>> Major Computing, Inc
> >> >>> --
> >> >>>
> >> >>> Not by age, but by knowledge is wisdom acquired.
> >> >>>
> >> >>>
> >> --------------------​--------------------​--------------------​--------
> >> >>> -
> >> >>> 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
> >> >>
> >> >>
> >> >
> >> >
> >> --------------------​--------------------​--------------------​---------
> >> > 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
> >>
> >>
> >
> >
> > --
> > ~
> > Pedram Nimreezi -- President/Senior Engineer
> > Major Computing, Inc
> > --
> >
> > Not by age, but by knowledge is wisdom acquired.
> > <screenshot.jpg>
> > --------------------​--------------------​--------------------​---------
> > 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
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.
Page: of 2 « Previous | Next »
Messages per page: