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 =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Full name =?ISO-8859-1?Q?David_Z=FClke?= <dz@bitxtender.com>
Date 2006-10-01 10:50:02 PDT
Message http://news.php.net/​php.apc.dev/8

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