Hmm... Not sure about the performance impact... As I'm using APC anywhere, I'm not considering the includes a trouble anymore... Anyway, here's an example of how I integrated the view with just a couple of lines of code: http://pastebin.com/jiFWEfDB I'm not noticing more than 10 msecs of time used when creating PHPTAL instance this way... This when running on Xen VPS, Intel i7-920, limited to 1 core, cap to 90% of the cpu clock, 128Mb of ram dedicated to APC (apc.stat=1)... Marco Pivetta @Ocramius <http://twitter.com/Ocramius> http://marco-pivetta.com
2010/12/22 Robert Goldsmith <rgoldsm...@names.co.uk> > > Hello :) > > Sorry for not replying to everyone's comments but I'm on holiday for > christmas :) > > Regarding Marco's comment on Zend_Application_Resource_Interface I would > guess it is a question of how Ztal is loaded into a Zend Application. We > initially used a combination of application resource helper and action > helper, as is the 'normal' way used by many > other integration projects (for PHPTAL, Smarty etc.) but found the > performance hit to be unacceptable. Both helpers make extensive use > of introspection and a many-to-many mapping in the autoloader which makes > them slow as well as hard to debug and sometimes unpredictable > (all problems the ZF guys are aware of and something ZF2 plans to tackle in > radical and most likely non-ZF1-compatible ways). > > Instead, we go for a plugin approach and setup our replacement View object > pre-dispatch. This way the View is available before the controller action is > triggered but it already has enough information to map a route to a module, > controller and action and can, therefore, correctly setup the paths needed > to load the correct templates for the module. One known limitation of this > is that internal redirects (rather than browser redirects) to a different > module are not currently captured and the paths will be incorrect for > loading the templates. I have some ideas on this but the gain from this > sacrifice is ~ 80ms performance gain which, in my tests, is about 20% of the > entire execution time of a 'normal' action in my fully loaded apps (with > caching, translation support etc.). > > Obviously we are working hard to document all of this and certainly in the > new year I will do my best to answer any and all questions from everyone :) > As a company we are pretty new to the process of releasing an open source > project so please be patient ;) As it says in the sparse documentation we > have already released we plan to camp out in #ztal on freenode for anyone > who has questions. As I'm sure everyone will agree, this mailing list is not > the place to really discuss Ztal but I really hope there can be a good > relationship between the projects. > > In case anyone wondered, we are already using Ztal internally on projects > and fully intend all future development to include Ztal and PHPTAL. We've > been using Ztal in various ways for over a year and already serve tens of > thousands of requests a day using the technology (in Italian and English) > across our company intranet. Our next step is upgrading some of our customer > facing services where, as we roll out the upgrades, we expect hundreds of > thousands and then millions of daily page hits. > > Robert Goldsmith > > On Sun, 19 Dec 2010 13:31:44 +0100, Marco Pivetta wrote: > > > Robert, do you have any Zend_Application_Resource_Interface resource in > the code-base? Didn't see any (had only 10 mins to look at Ztal till > now)... > Marco Pivetta > @Ocramius [1] > http://marco-pivetta.com [2] > > > > _______________________________________________ > PHPTAL mailing list > PHPTAL@lists.motion-twin.com > http://lists.motion-twin.com/mailman/listinfo/phptal >
_______________________________________________ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal
