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

Yes, Pedram, I think we're all in agreement that you can do what youwill with PHP4-Propel. I never heard back from Michael, but, assumingyou also didn't hear anything, I'm guessing that he's ok with the oldPHP4 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>

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

David's tone may have been a bit brusque, but it's probably a culturaldifference more than a personal one. In any event, he's right thatwe're not concerning ourselves with PHP4, not after PHP5 has been outfor years. PHP4 may exist in legacy applications, but it is dead fornew project development. PEAR is about to require all new packages bePHP5, which (given PEAR's relatively conservative outlook) is a prettygood 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 hearsayabout engine internals, he took the time to write to internals and findout why it was behaving as it is.

Anyway, we are all enterprise programmers here. And I think thisproject is extremely open to contributions and suggestions. You arewelcome to propose additions to the generator and/or runtime, and I'mconfident 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 codeaccepted, if you are able to work with others on the list in aconstructive 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>>>>> >

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 todayand I've been programming for 15 years... php 4 will bedead in about 3 years... it's not dead yet... and net yearsare like dog years.... I'm an enterprise programmer whatmaybe great for everybody is buggy inconsistency for me...Not everyone has the same stringent requirements yeteveryone is very quick to jump in to add what they've"heard" .... Ignoring the fact that I have actual tests andyears 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>>

> 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 myeyes (and only bug fixed by some bigger companies that rely on it [say:eZ]).

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

> 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 ofPHP. The Class/Function/Object-model is built upon every new request.Opcode Caches just eliminate parsing and compiling, but everyclass/function must be registered in the engine though.

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

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 fileapproach and the autoload method that's being worked on now. I'mguessing that the single big file would lose out without an opcacheexcept in the rare circumstance where you're working with basicallyall of the classes for a request. It'd be a little more interesting tosee how each did with the opcache.

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 aboutopen-source software (though I'd say that it's a fairly small part ofthe benefit).

Another option would be to write a Phing task that builds all dependencyclasses into a single file. This doesn't seem that difficult -- andit's what Phing is great at. Then users can "build out" their Propelpackage for performance reasons if they want to have everything packagedin a single file. I don't see why this would be incompatible with otherideas proposed.

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

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 5and 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 agoand 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 2years 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>>

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 somepreliminary code from Ants for the Criteria2 work that he'd done. I'mgoing to look through that and see how to go about wiring that intoPropel, what needs work still, etc. So, Propel trunk will break anybackwards compatibility -- even with the existing trunk code. We'vebeen saying that for awhile. That's why it's not released ;)

I'm not arguing to the instability nor the missing features, its justwhat im using and I like it and until recently 1.x required creole andi 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

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

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

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 wayfor 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 sowe'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

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.

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

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

>> 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 Propel2.0 classes/modules.

My issue is with doSelectJoinBlah where blah is a parent table in aone to many relationship and i am pulling upwards of 2000 records fromthe child table. If i remove the require_once and put it at the top ofthe php file its fast, if i dont it sits there for centuries reopeningthe file over and over again. This problem is DEFINANTLY worse on my64bit workstation compared to the 32bit servers i have sitting hereand 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 issueswith and currently iv tried latest php 5.1 in portage, php 5.1 fromcvs and 5.2 from cvs, all with/without xdebug/eaccel and have found itto make basically no real difference.

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

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

if you want some hard numbers i can get them out of it again, i justthrew up my hands when i realized what was wrong and decided that weneeded to do something about this when we are working with so manyobjects 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

Sorry if i sounded rather blunt in that message but there hasnt beenmuch work done on 2.0 for a while and im starting to hit someperformance related issues so i wanted to make sure if i jumped in thedeep end that i wouldnt make a mess of something someone else isdoing. I'm just going thru all these emails now and will work out whati 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

for ajax and other asynchronous low latency requests theres a mark improvement.With opcode caching (eaccelerator/apc) I get about 110 and without Iget about 55...that was when i last bench marked, my framework has an abstraction forthe sessionhandler, when I switch from CreoleSession to MemcacheSession I can get somerequests to over 50% faster execution. There's also a difference in a scenariowhere you want the session to always have the "latest" data, forinstance if it wasshifted by a foreign process (like an auction bid) or something lessreal-time...I go for real-time... I've demonstrated this with my web based IRC chat whichis 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 therequests are asynchronously made and its a retrieve and terminate connection,with Comet the connection is never closed and a PHP output buffering flushingtechnique does the incremental updates (with js) so that the servercan cause events tofire on the browser side at the servers command. for instance (userenters channel)or (sysop requests your permission to send you a video clip)... theseare all thesectors of web application design that are emerging and are seriously lackingin discussion or accepted technique.... I'd love to commit my work forconsumption...Including the realtime irc web chat which I can also open source thatuses littledhtml 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 inPECL 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 rightimplementation because its "hard" isnt correct attitude, I'd love to see afull propel PECL so that I can have all the code I need (forframework/maintainability)but already built into PHP so theres not such a speed loss coming outthe 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>>