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 Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-10-01 20:09:57 PDT
Message for ajax and other asynchronous low latency requests theres a mark improvement.
With opcode caching (eaccelerator/apc) I get about 110 and without I
get about 55...
that was when i last bench marked, my framework has an abstraction for
the session
handler, when I switch from CreoleSession to MemcacheSession I can get some
requests to over 50% faster execution. There's also a difference in a scenario
where you want the session to always have the "latest" data, for
instance if it was
shifted by a foreign process (like an auction bid) or something less
real-time...
I go for real-time... I've demonstrated this with my web based IRC chat which
is pretty close to real-time and uses no plugins or outmoded polling methods.
Difference between the ajax and comet systems I have is that with Ajax the
requests are asynchronously made and its a retrieve and terminate connection,
with Comet the connection is never closed and a PHP output buffering flushing
technique does the incremental updates (with js) so that the server
can cause events to
fire on the browser side at the servers command. for instance (user
enters channel)
or (sysop requests your permission to send you a video clip)... these
are all the
sectors of web application design that are emerging and are seriously lacking
in discussion or accepted technique.... I'd love to commit my work for
consumption...
Including the realtime irc web chat which I can also open source that
uses little
dhtml in browser windows and utlizes the Smart_IRC lib from pear..
(its one of the good ones) btw I have this connection layer also implemented in
PECL so that it can handle much much higher scalability...

ps.. when part of the structure needs to be faster... you make it in c/c++...
in most cases its not needed but knowing when and not avoiding the right
implementation because its "hard" isnt correct attitude, I'd love to see a
full propel PECL so that I can have all the code I need (for
framework/maintainability)
but already built into PHP so theres not such a speed loss coming out
the gate...

that's my two cents... feel free to refund ;-)


On 10/1/06, Alan Pinstein <apinstein at mac dot com> wrote:
> 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
>
> --------------------​--------------------​--------------------​---------
> 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.

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