Re: [Cheetahtemplate-discuss] performance improvements (was "transactions and function calls")

[Tavis R. <ta...@re...>]

On Monday 14 November 2005 11:47, Shannon -jj Behrens wrote:
> On 11/12/05, Tavis Rudd <ta...@re...> wrote:
...
> > Cheetah version 1.0rc2 (in the cvs) has the following performance related
> > changes:
> > - faster list-based buffering in DummyTrans, rather than StringIO (my
>
> Interesting.  You know, StringIO already uses a list and only creates
> a full string under certain conditions.  Does your code automatically
> pass the same list in when it calls a Cheetah template/function?  I
> have thought for a long time that that would be a good improvement.
> You'd have to differentiate:
>
> $foo  ## Where foo is a Cheetah method that knows how to accept the buf
> list. $bar ## Where bar is a Python method that doesn't know how to accept
> the buf list.
> #set a = $foo ## You can't use a buf list because you're expecting
> output from foo.
>
> Does that make any sense?

Unfortunately, that's not possible.  

However, the cvs version does something that has the same effect.  If you 
assign a transaction object (a real one or a Cheetah.DummyTransaction) to 
template.transaction, the template will use the 
transaction.response().write() for all output rather than returning a string 
for each method call.  See Jonathan's post and have a look at the code output 
by the cvs version for more details.

> > benchmarks showed it to be significantly faster.  collections.deque
> > wasn't any faster than a simple list.)
> > - new CompilerSettings to tweak generated code:
> >   * alwaysFilterNone: filter out None immediately, before the filter is
> > called * useFilters: allows you to turn them off completely and default
> > to str() * includeRawExprInFilterArgs: allows you to disable this
> > behaviour - and automatic $trans finding without having to pass it as an
> > arg to methods
>
> I forget, is it possible to use the NameMapper to get into Python
> expression context *without* all the other NameMapper magic, that is
> to turn off all the searchList, auto dictionary/attribute/function
> call magic?  
Well, that's all that NameMapper is.  If you don't use that stuff, you can add 
the compiler setting useNameMapper=False and you'll see a huge increase in 
performance.

> At work, we're stuck using the Python version of the 
> NameMapper for *extremely esoteric* reasons, and our performance tests
> show NameMapper's functions accounting for 30% of our CPU time :-/

I bet this is because of the stack frame lookups being done in Python.  Just 
using the compiler setting useStackFrames=False will yield big gains.  Like I 
wrote in the original post, this is done automatically in the new version if 
don't have the C version installed.