<p>I believe mozilla worked on this issue. if.you're interested in this perhaps we should get you in contact with them.</p>
<div class="gmail_quote">On Aug 20, 2011 3:35 AM, "Hakan Ardo" <<a href="mailto:hakan@debian.org">hakan@debian.org</a>> wrote:<br type="attribution">> Hi,<br>> I've been experimenting a bit with heuristics such as "not retracing<br>
> loops with a lot of guards" or "not unrolling if the peel loop is not<br>> much better than the preamble". In some situations is seem possible to<br>> increase performace by such means (go: +37%, html5lib: +13%, rietveld:<br>
> +8%). However I think the real problem is that we duplicate guards and<br>> that this leads to an explosion of bridges. I added<br>> test_excessive_bridgeing to test_ajit on the jit-limit_peeling branch.<br>> It is a simple example where the last part of the loop is traced 8<br>
> times producing 8 identical bridges.<br>> <br>> Is there any chance of identifying copies of "the same guard" (in some<br>> sens that considers both the address of the guard and the state of<br>> virtuals) and when the second copy of the guards is about to be traced<br>
> we would just connect it to the already compiled bridge? Maybe by<br>> producing a small header-bridge that moves things around and then<br>> jumps to the already compiled bridge?<br>> <br>> -- <br>> Håkan Ardö<br>
> _______________________________________________<br>> pypy-dev mailing list<br>> <a href="mailto:pypy-dev@python.org">pypy-dev@python.org</a><br>> <a href="http://mail.python.org/mailman/listinfo/pypy-dev">http://mail.python.org/mailman/listinfo/pypy-dev</a><br>
</div>