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

2010/12/22 Robert Goldsmith <>

> 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]
> [2]
> _______________________________________________
> PHPTAL mailing list
PHPTAL mailing list

Reply via email to