Hi.
Sorry, for the double post, the incredibly bad Google Groups UI didn't
seem to accept my post and wasn't giving a hint at the moderation for
first time posters.
Michael Bayer wrote:
> Yeah, so here is the mako render() method for that template:
>
> def render_body(context,**pageargs):
> context.caller_stack._push_frame()
> try:
> __M_locals = __M_dict_builtin(pageargs=pageargs)
> table = context.get('table', UNDEFINED)
> __M_writer = context.writer()
> # SOURCE LINE 1
> __M_writer(u'\n<table>\n')
> # SOURCE LINE 3
> for row in table:
> # SOURCE LINE 4
> __M_writer(u' <tr>\n')
> # SOURCE LINE 5
> for col in row.values():
> # SOURCE LINE 6
> __M_writer(u' <td>')
> __M_writer(filters.html_escape(unicode( col )))
> __M_writer(u'</td>\n')
> # SOURCE LINE 8
> __M_writer(u' </tr>\n')
> # SOURCE LINE 10
> __M_writer(u'</table>\n')
> return ''
> finally:
> context.caller_stack._pop_frame()
Hhm, somewhat obfuscated code ;)
> I think this source code is extremely comparable to the z3c.pt
> code....the Mako has less initialization code at the top. You might
> want to maybe test against a wider range of template designs to get a
> better picture of the speed differenes.
The speed comparison using the bigtable test obviously doesn't tell
you much about any real application level speed. We tend to have lots
of quite small templates and all of them use full
internationalization, which both change the performance
characteristics quite a lot. We'll invest more time to optimize the
i18n support instead, which has more potential performance gain.
> Is it literally just the
> html_escape(unicode()) that makes z3c 2x the speed ? Cheetah as
> well ? It seems like Mako could apply the exact same optimizations
> with no trouble at all.
I'm sure it can. I would just try to benchmark the above code on its
own and see what can be optimized. For example defining something
like:
_html_escape = filters.html_escape
outside the loop might help.
Our _out uses a list that looks like this:
class BufferIO(list):
write = list.append
def getvalue(self):
return ''.join(self)
and for the cgi.escape function we use a slightly optimized version as
well. It seems not creating new strings through replace all the time
saves quite a lot:
def _escape(s, quote=0, string=1):
"""Replace special characters '&', '<' and '>' by SGML entities.
If string is set to False, we are dealing with Unicode input.
"""
if string:
s = str(s)
if '&' in s:
s = s.replace("&", "&") # Must be done first!
if '<' in s:
s = s.replace("<", "<")
if '>' in s:
s = s.replace(">", ">")
if quote:
s = s.replace('"', """)
return s
>> spitfire's main trick is to first generate a Python abstract syntax
>> tree out of the template and then have multiple loops of various
>> optimization's being applied to that tree, so it can optimize away
>> even more.
>
> well if you've generated Python code as we've done here, you can get
> an AST from that. I think its the "various optimizations" part here
> that is somewhat mysterious :) .
It is not mysterious but very complicated and hard to read code for my
taste. Have a sneak peek at http://spitfire.googlecode.com/svn/trunk
and see for yourself ;) It basically first generate an AST from a
template, then optimizes the tree and as a last step creates the
render function like code we have here.
> Are you planning on applying Spitfire's techniques to z3c? If so, I
> might as well do whatever you're doing too since the code generation
> is extremely similar.
I'm not intending to apply more of spitfire's techniques to z3c.pt.
Our main motivation was to make zope.pagetemplate / zope.tal faster by
an order of magnitude. We have arrived at that stage now, with a
pretty small and slick code base. Currently we don't need to have a
separate optimizations phase in the code.
Any attempt to make z3c.pt go faster would basically mean to fork
spitfire at this point. So we will instead invest the time to extend
the existing support for a TAL-like language in spitfire up to a point
where it is usable and feature complete.
Most of this is driven by the Zope / Plone communities and we have
some initial plans to replace our usage of zope.tal in the next major
Plone version with z3c.pt and hopefully have spitfire ready to be used
instead in the major version after it.
Hanno
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
