Login | Register
My pages Projects Community openCollabNet

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

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


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

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

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


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