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 Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-10-01 14:50:44 PDT
Message 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

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 12:35:38 PDT
Message 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.
Attachments

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-01 11:19:50 PDT
Message 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
>

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-01 10:50:02 PDT
Message 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
>
>

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-01 10:40:56 PDT
Message 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
>

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 09:59:57 PDT
Message 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.

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-01 09:50:26 PDT
Message > 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

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 09:38:18 PDT
Message I took out 99% of the _once stuff from the php4/php5 compatible distro of
creole and propel... btw I asked about this all the way to the top...
here's what I got.


[11:18] DaedZen: i should pretty much remove all include_once/require_once's
[11:18] Rasmus: DaedZen: never use any of those Daed.. no conditional
declarations, no include_once, no autoload
[11:19] DaedZen: they wouldn't reinclude anyway.. I just do that from habit
[11:19] DaedZen: ok so i can safely take them out
[11:19] Rasmus: There are 2 separate problems with include_once.
First, it is optimized for non-opcode cache use in that it always
opens the file
[11:19] DaedZen: oh well thats good to know
[11:20] Rasmus: that means you touch the disk when you don't need to.
And second, it means any declarations in that op_array are now
conditional and thus will have to be done at execute time
[11:20] Rasmus: yes, it is a very very bad habit to always use include_once
[11:20] Rasmus: might as well put a sleep 1 in all your scripts
[11:20] DaedZen: ouch
[11:20] DaedZen: understood

note: (Rasmus is obviously being jovial about the sleep 1, but also
being honest)

I have MY version of creole and propel which again works in both versions of
the zend engine and tries its absolute level best to avoid the use of
conditional
declarations, include/require_once's or autoloading... but remember my
version is optimized for ajax and comet and json and seo and cms all
the stuff people don't necessarily or summarily include in their
benchmarks or development schedules... that are to me, today, (required).

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)

I've seen requests per second for these setups to be as low as
8 to 10 requests per second... if Mambo/Joomla can provide 50 times the
functionality at the same speed, and is more than a skeleton
framework well.. that is just unfortunate.

I don't like the CMS approach to php application design because its
mostly procedural and phpnukish in its design, which is the reason I
had to design Rapid Framework which is a clandestine mix of these
requirements but with a simple way to augment the framework
functionality (adding controllers) and having search
engine friendly url's and adding content and ajax and comet and many
other features I haven't had time to do a full write up on... which
I'll be happy to give
away... thus the reason I asked about the PHP like BSD licensing for the
php 4 version instead of the LGPL licensing, which I've never really
gotten a clear
answer on....

The "proper" CMS approach to web site design is an exceptionally strong method
of achieving high search engine visibility, and lots of traffic, it
works off a set of
"rules" that very few developers have even the foggiest idea of and
usually only
identify to the "odd behaviour" of "mediocre sites" having "so much
more traffic"
then their fine craftsmanship... it all comes down to application design where
one is coded to be effective and one is coded to be pretty, I went for both, I
like very very clean code and very very high search engine rankings which
can be combined but usually aren't because the developers are from entirely
different schools...

/acme-h15-long-range​-coyote-hunting-rifl​e.html is always going to beat,
?module=cart&act​ion=product&id=5​ even /cart/products/5.html or a variation

but that doesn't mean the first url cannot imply that it means the second url.

And these are some of the things I needed, didn't have correctly and
had to make.

Let me know if you guys need anything more of me...



On 10/1/06, David Zülke <dz at bitxtender dot com> wrote:
> > 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.
>
> Prior to 5.2 and the latest APC, _once calls were not accelerated _at
> all_ by APC because there was no way for a cache to hook in.
>
>
> > 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).
>
> It is slower than a regular require. I recently threw out all but one
> _once call from Agavi, and with APC (on 5.0.4), the page rendering
> time dropped by 50(!) percent.
>
>
> > 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.
>
> Of course. Using _once inside an autoload is utterly stupid. Why
> would you do that. It only gets called when the class was not found
> anyway ;)
>
> I emailed the APC dev list during the discussion in the other thread,
> and Rasmus said that while dynamic/conditional loads (e.g. a require
> inside an if, or an autoload) are accelerated by APC, too, there
> won't be the same amount of improvement over a straight require(). I
> still believe that autoload is the better solution; not only because
> it makes things cleaner, but also because it offers the most fine-
> grained JIT-style loading you could possibly have with next to no
> effort as opposed to require calls, where you might end up loading
> more than you need in the specific situation.
>
>
> > - 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.
>
> We had some guys on #agavi who did that since APC prior to PHP 5.2
> would randomly produce errors about classes not found - turned out
> the _once stuff was the problem.
>
>
> 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.

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-01 09:18:14 PDT
Message Ok, interesting... so you're saying the best thing to do then is to
switch to full autoload, using require() inside of the autoload, and
that should make propel opcocde-cache "compliant" (for lack of a
better word)?

If so, then it sounds like we've got our solution!

BTW - I am gonna go try out some of this on my framework too... see
if it speeds up with APC!

Alan


On Oct 1, 2006, at 11:47 AM, David Zülke wrote:

>> 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.
>
> Prior to 5.2 and the latest APC, _once calls were not accelerated
> _at all_ by APC because there was no way for a cache to hook in.
>
>
>> 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).
>
> It is slower than a regular require. I recently threw out all but
> one _once call from Agavi, and with APC (on 5.0.4), the page
> rendering time dropped by 50(!) percent.
>
>
>> 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.
>
> Of course. Using _once inside an autoload is utterly stupid. Why
> would you do that. It only gets called when the class was not found
> anyway ;)
>
> I emailed the APC dev list during the discussion in the other
> thread, and Rasmus said that while dynamic/conditional loads (e.g.
> a require inside an if, or an autoload) are accelerated by APC,
> too, there won't be the same amount of improvement over a straight
> require(). I still believe that autoload is the better solution;
> not only because it makes things cleaner, but also because it
> offers the most fine-grained JIT-style loading you could possibly
> have with next to no effort as opposed to require calls, where you
> might end up loading more than you need in the specific situation.
>
>
>> - 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.
>
> We had some guys on #agavi who did that since APC prior to PHP 5.2
> would randomly produce errors about classes not found - turned out
> the _once stuff was the problem.
>
>
> David
>
> --------------------​--------------------​--------------------​---------
> 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-01 08:47:42 PDT
Message > 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.

Prior to 5.2 and the latest APC, _once calls were not accelerated _at
all_ by APC because there was no way for a cache to hook in.


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

It is slower than a regular require. I recently threw out all but one
_once call from Agavi, and with APC (on 5.0.4), the page rendering
time dropped by 50(!) percent.


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

Of course. Using _once inside an autoload is utterly stupid. Why
would you do that. It only gets called when the class was not found
anyway ;)

I emailed the APC dev list during the discussion in the other thread,
and Rasmus said that while dynamic/conditional loads (e.g. a require
inside an if, or an autoload) are accelerated by APC, too, there
won't be the same amount of improvement over a straight require(). I
still believe that autoload is the better solution; not only because
it makes things cleaner, but also because it offers the most fine-
grained JIT-style loading you could possibly have with next to no
effort as opposed to require calls, where you might end up loading
more than you need in the specific situation.


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

We had some guys on #agavi who did that since APC prior to PHP 5.2
would randomly produce errors about classes not found - turned out
the _once stuff was the problem.


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-01 08:36:02 PDT
Message 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 Alan Pinstein <apinstein at mac dot com>
Full name Alan Pinstein <apinstein at mac dot com>
Date 2006-10-01 08:08:20 PDT
Message Thanks guys!

Cameron-

Yes, I have been working / thinking on this issue a lot. I have
already committed all of my autoload patches to the 1.3 branch and
tested them - they are working. In fact, I'll go update my ticket now...

Here's the ticket for autoload:

http://propel.phpdb.​org/trac/ticket/198

[ ok, side note, I have *no* idea how to edit my ticket... I am
logged in, and I can view the ticket, but I don't see an "edit" link
anywhere... tried on Safari and Firefox... help! ]

So anyway, I have completed #1. David had an excellent idea for #2:

> As far as the generated classes are concerned, I was thinking about
> either including the list of classes and their file names in the
> runtime config, so Propel::init() would load these, or having a
> separate file for each package that contains the spl_autoload
> definition and is loaded on init().

I think that this will work perfectly. I have yet to thing of a
single thing wrong with it.

As for #3, this is easily solved with the spl_autload stuff. I have
already committed a stub spl_autoload-compatible autoload for propel
as Propel::autoload($className) which is working, and I am using it
in my projects. However, I only have it set up presently to load the
files that you previously had to do anyway (ie criteria, creole, etc)
so as to not cause any BC problems. If we're committing to
spl_autoload, then we need only go through all of the files looking
for require/includes and move it all over to this function. This
should be easy. I can do it, if people would like, or David can do it
when he fixes up the runtime-conf autoload stuff.

Alan

On Oct 1, 2006, at 9:10 AM, Hans Lellelid 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
>>
>> --------------------​--------------------​--------------------​---------
>> 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-01 07:22:51 PDT
Message Cameron,

Alan already committed something in that direction to the 1.3 branch.
We agreed to bump the minimum PHP version for Propel 1.3 to 5.1 so we
can use SPL autoloading and maybe some other nice stuff. I already
proposed a way to load the generated classes at runtime, I hope I'll
get to implement and commit it later today.

David


Am 01.10.2006 um 10:50 schrieb Cameron Brunner:

> 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 hlellelid
Full name Hans Lellelid
Date 2006-10-01 06:10:24 PDT
Message 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
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

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-01 01:50:23 PDT
Message 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
Page: of 2 « Previous | Next »
Messages per page: