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


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