I'm not modifying any benchmark or framework. At best I will replace Mako 0.7.2 with Mako 0.7.3 in the benchmark suite since no one is historically recording the mako_v2 benchmark yet and it should be running with the newest version until we set it in stone.<div class="gmail_extra">

<br><br><div class="gmail_quote">On Sat, Nov 3, 2012 at 10:48 AM, Maciej Fijalkowski <span dir="ltr"><<a href="mailto:fijall@gmail.com" target="_blank">fijall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="HOEnZb"><div class="h5">On Fri, Nov 2, 2012 at 8:42 PM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> Issue filed for the performance issue: <a href="http://bugs.python.org/issue16390" target="_blank">http://bugs.python.org/issue16390</a><br>
><br>
> With that change and running on tip of Mako on my laptop now reports 1.25x<br>
> slower which is much better than it was. This performance issue might also<br>
> explain why all of the regex compilation benchmarks are worse under Python<br>
> 3.3 by a decent margin.<br>
><br>
> On Fri, Nov 2, 2012 at 2:16 PM, Philip Jenvey <<a href="mailto:pjenvey@underboss.org">pjenvey@underboss.org</a>> wrote:<br>
>><br>
>> lru_cache on re._compile_typed<br>
<br>
</div></div>I would like to warn you about modifying benchmarks like this (or<br>
frameworks). Why is it relevant anyway?<br>
</blockquote></div><br></div>