I've thinking about how to squeeze some extra performance from phptal
at runtime (compile time doesn't matter to me). For what I've seen in
the code generated the most expensive function is phptal_path(), which
does a fair amount of introspection to find how to traverse a tales
path based on a PHP object/array structure.

The thing is that the most intense operation is a loop (tal:repeat),
so if I have 5 paths inside a loop and it has to loop 100 times, the
phptal_path() function is being called 500 times. So I've been playing
with an alternative approach, instead of traversing the data structure
each time at runtime, I'm moved this function to the Context object
and I keep a cache dictionary in it which the key is the path and the
value an eval() suitable string. If a path is requested and not in the
cache, the method builds the eval string for it and caches it. The
next time that path is requested it just evals the cached string and
returns the result, avoiding to introspect the data which is

The only problem I see is that if someone supplies a set of data which
aggregates objects of different nature. Since the php evaled is
computed on the first iteration, the following iterations assume that
the data on which they operate has the exact same format. I don't
think this is a common practice (I haven't seen something like that

Any comments on this?

PS: I've been also thinking about moving all the phptal_xxx functions
to methods in the Context class, so the code is more self contained
and allowing in the future to extend the Context object with custom

PHPTAL mailing list

Reply via email to