Login | Register
My pages Projects Community openCollabNet

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

propel
Discussion topic

Back to topic list

Re: [propel-dev] Propel 2.0 spl_autoload

Reply

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

« Previous message in topic | 13 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: