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 14:50:44 PDT
Message So you have one HUGE file... how is performance? With opcode cache?
Without? Because it's a serious consideration to shift to "requiring
opcode cache" for propel...

Alan

On Oct 1, 2006, at 3:35 PM, Pedram Nimreezi wrote:

> Alan you are expertly describing a problem that unfortunately
> I did spend an unordinate waste of time turning a viable solution
> out of..
> that I believe are up to everyones standards, its a big damn file yes,
> but there are very clean ways of working with it, attached is a
> screenshot,
> another example like the Widget one you described is the
> Connection.php
> plugin files for the various database abstractions, (I left those
> things plugins)
> without _once's, In fact the loading of those plugins based on the
> type of
> database you are accessing is an example of a conditional inclusion
> which
> is in this case an example of you may not be able to take ALL of
> them out,
> but 99% is still a very good accomplishment... attached is a
> screenshot
> of VIM, each class is collapsable and editing is very fast, and
> this file
> needs only to be included... my framework allows you to create
> systems, controllers and actions that are EASY to work with they are
> basically directories, objects and methods and evoke an organizing
> trait
> that is hard to find... especially by procedural programmers or
> people who
> make programs they hate to maintain...
>
>
> On 10/1/06, Alan Pinstein <apinstein at mac dot com> wrote:
>> 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
>> >
>>
>> --------------------​--------------------​--------------------​---------
>> 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.
> <screenshot.jpg>
> --------------------​--------------------​--------------------​---------
> 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 | 16 of 40 | Next message in topic »

Messages

Show all messages in topic

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-01 01:50:23 PDT
     Re: [propel-dev] Propel 2.0 spl_autoload hlellelid Hans Lellelid 2006-10-01 06:10:24 PDT
         Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 08:08:20 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-02 22:41:01 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-01 07:22:51 PDT
     Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 08:36:02 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-01 08:47:42 PDT
             Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 09:18:14 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-01 09:38:18 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-01 09:50:26 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-01 09:59:57 PDT
                         Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 10:40:56 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-01 10:50:02 PDT
                                 Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 11:19:50 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-01 12:35:38 PDT
                                         Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-01 14:50:44 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-01 20:09:57 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-02 22:51:24 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 03:44:33 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 04:04:09 PDT
             Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-03 05:53:17 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 06:11:27 PDT
                     Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-03 06:19:24 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 07:30:28 PDT
                     Re: [propel-dev] Propel 2.0 spl_autoload Alan Pinstein <apinstein at mac dot com> Alan Pinstein <apinstein at mac dot com> 2006-10-03 07:57:51 PDT
Page: of 2 « Previous | Next »
Messages per page: