On Sat, Aug 20, 2011 at 18:04, Hakan Ardo wrote:
> On 8/20/11, Alex Gaynor wrote:
>> I believe mozilla worked on this issue. if.you're interested in this
>> perhaps we should get you in contact with them.
>
> Good idea. Do you have some contact?
You might just drop into #jsapi on irc.mozilla.or
On 8/20/11, Alex Gaynor wrote:
> I believe mozilla worked on this issue. if.you're interested in this
> perhaps we should get you in contact with them.
Good idea. Do you have some contact?
Does the following approach make sens:
When a guard is traced we trace to the next jit_merge_point() only
I believe mozilla worked on this issue. if.you're interested in this
perhaps we should get you in contact with them.
On Aug 20, 2011 3:35 AM, "Hakan Ardo" wrote:
> Hi,
> I've been experimenting a bit with heuristics such as "not retracing
> loops with a lot of guards" or "not unrolling if the pee
Hi,
I've been experimenting a bit with heuristics such as "not retracing
loops with a lot of guards" or "not unrolling if the peel loop is not
much better than the preamble". In some situations is seem possible to
increase performace by such means (go: +37%, html5lib: +13%, rietveld:
+8%). However
