[Grok-dev] megrok.chameleon template engine
sebastian at urbantalk.se
Tue Feb 24 07:06:26 EST 2009
Did I understand it correctly that Chameleon only supports TALES
23 feb 2009 kl. 22.40 skrev Uli Fouquet:
> Hi there,
> Martijn Faassen wrote:
>> Thanks for doing this work Uli! I really like all the activity
>> surrounding alternative template languages in Grok now. For a while I
>> thought the work at the Neanderthal sprint to support other template
>> languages was not really going to be used by anyone, as it was very
>> quiet surrounding the topic, but it looks like things are changing.
> It was really easy. Thanks to all who brought the templating-support
>> Uli Fouquet wrote:
>>> Wichert Akkerman wrote:
>>>> Previously Uli Fouquet wrote:
>>>>> It provides support for chameleon-driven Zope page templates and
>>>>> for Genshi templates. Chameleon is the template engine also used
>>>>> repoze.bft and it (chameleon) is said to be faster than regular
>>>>> page templates.
>>>> By a factor of 12 currently if I remember correctly.
>>> Hm, currently I cannot reproduce such speedup. Maybe my
>>> is really bad or we have a more general problem with template-
>>> in Grok/Zope.
>> It could be that non-template handling time is dominating in your
> Of course! The template rendering time looks minimal compared with the
> main publishing stuff.
> But in my (silly, incomplete, non-authorative) profiling tests I only
> compared the times for template rendering with following results
> rendering the standard 'congratulations' template (no substitutions,
> * with ZPT template: 2.10% (of whole request)
> * with CPT template: 0.65% (of whole request)
> If we reflect the profiler impact (> 50% of a request), this means
> we're talking about a piece that with regular ZPT eats more than
> 4.2% of
> (non-profiling) request time while with CPT it costs you only about
> (for this particular template).
> This, however, is far away from the 12x speedup I'd dream of (but,
> more than three times faster isn't _that_ bad, is it?).
>> Anyway, I'd like to see lots more people doing lots more profiling
>> Grok so we can track down issues like this and gain a better
>> understanding for where time is going now, and where we should spend
>> efforts to make things faster.
> I might start with a profiling HOWTO, that brings the pieces together
> one needs.
> Maybe we should share some statistics or graphics somewhere? On the
> Grok-site maybe?
> Best regars,
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev