Login | Register
My pages Projects Community openCollabNet

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

propel
Discussion topic

Back to topic list

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

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

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

Messages

Show all messages in topic

                         Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-03 08:12:02 PDT
                             Re: [propel-dev] Propel 2.0 spl_autoload Cameron Brunner <cameron dot brunner at gmail dot com> Cameron Brunner <cameron dot brunner at gmail dot com> 2006-10-03 08:23:53 PDT
                         Re: [propel-dev] Propel 2.0 spl_autoload hlellelid Hans Lellelid 2006-10-03 10:47:11 PDT
                             Re: [propel-dev] Propel 2.0 spl_autoload Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2006-10-03 12:19:32 PDT
                                 Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-03 12:31:40 PDT
                                 Re: [propel-dev] Propel 2.0 spl_autoload hlellelid Hans Lellelid 2006-10-03 12:47:04 PDT
                                     Re: [propel-dev] Propel 2.0 spl_autoload Scott Wehrenberg <swehren at gmail dot com> Scott Wehrenberg <swehren at gmail dot com> 2006-10-03 12:50:16 PDT
                                         Re: [propel-dev] Propel 2.0 spl_autoload Soenke Ruempler <soenke at ruempler dot eu> Soenke Ruempler <soenke at ruempler dot eu> 2006-10-03 14:05:28 PDT
                                             Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-03 14:12:28 PDT
                                 Re: [propel-dev] Propel 2.0 spl_autoload Soenke Ruempler <soenke at ruempler dot eu> Soenke Ruempler <soenke at ruempler dot eu> 2006-10-03 15:07:25 PDT
                                     Re: [propel-dev] Propel 2.0 spl_autoload Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2006-10-03 20:15:20 PDT
                                         Re: [propel-dev] Propel 2.0 spl_autoload hlellelid Hans Lellelid 2006-10-04 05:33:00 PDT
                                             Re: [propel-dev] Propel 2.0 spl_autoload =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> =?ISO-8859-1?Q?David_Z=FClke?= <dz at bitxtender dot com> 2006-10-04 06:04:48 PDT
                                                 Re: [propel-dev] Propel 2.0 spl_autoload hlellelid Hans Lellelid 2006-10-04 06:12:18 PDT
                                                     Re: [propel-dev] Propel 2.0 spl_autoload Pedram Nimreezi <zenstyle at gmail dot com> Pedram Nimreezi <zenstyle at gmail dot com> 2006-10-04 12:47:32 PDT
Page: of 2 « Previous | Next »
Messages per page: