On Fri, Apr 9, 2010 at 7:47 PM, Malthe Borch <mbo...@gmail.com> wrote:
> The approach we took was practical, or seemed practical. Maybe we
> should have used a different strategy:
Sure. I think the approach we took was good. It gave as a hugely
successful, stable and performant engine. I just have the feeling that
the current model has become somewhat convoluted and hinders us to do
any more optimizations. I certainly don't want to go anywhere near
what Spitfire did with its four different optimization stages. There
are things which are better left to JIT compilers like Unladen
Swallow.
> - phase 1: generate high-level code that employs function calls
> - phase 2: inline function calls or similar expansion
> - phase 3: code optimization
>
> Also, I realized while writing the ``curry`` library that things like
> temporary variables can be dealt with very efficiently by subclassing
> e.g. ``ast.Name`` into ``TemporaryName`` and simply extending the code
> generator.
I don't have a good enough understanding of the current code anymore,
to suggest a good approach. In my naive view I wanted have a tree
structure like:
RepeatNode
\-- AssignNode
\-- ConditionNode
\---- ContentNode
or something similar "high-level". For the repeat variable case, I'd
then want to take each RepeatNode and traverse it's inner nodes. If
the "repeat" variable is accessed the RepeatNode would get a flag set
and generate the corresponding code at a later stage. For this to
work, you need to be able to ask each Node for the variables it's
operating on.
Maybe you could also optimize the above tree to move the AssignNode
outside the loop, if it isn't dependent on the loop variable of the
RepeatNode. There's plenty other things you can do. I don't know which
ones of these make sense to have and which ones are better left to
Python itself.
But whenever I looked at the generated code for real-world templates,
done by non-computer scientists, there's been a huge number of
glaringly obvious inefficiencies. Most prominent things like doing too
much work inside loops, calling the same functions multiple times
without assigning the result to a temporary variable and such. Maybe
these should just generate warnings and tell the template author to
fix them. I've just seen pseudo-code like this too often:
<ul tal:repeat="item items">
<li tal:condition="view.useIcons()">
icon
</li>
<li tal:condition="not view.useIcons()">
text
</li>
</ul>
You can easily save 2 * len(items) function calls here, by using one
more temporary variable. I haven't figured out who or what code should
do something to avoid this yet :)
Hanno
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
