[Webkit-unassigned] [Bug 155551] Pathological performance on first execution of a function called with mismatched argument count

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=155551

--- Comment #3 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #2)
> Ok, so passing extra is still penalized, but nowhere near the same extent.
> 
> Also, if we call with extra arguments initially the no arguments case
> remains much more expensive.
> 
> Derp, timings in initial report were in a debug build, but that just makes
> the failure more apparent. Below timings are in a trunk release build and
> they're still showing a 4x hit.
> 
> A more curious failure is 
> 
> function f(j) { for (var i = 0 ; i < 10000000; i++) j = (j ?  j * i : 1) ^
> (i & j); }; 
> var start = new Date; f(1,2); var end = new Date; print("1st: " + (end -
> start) + "ms"); 
> var start = new Date; f(); var end = new Date; print("2nd: " + (end - start)
> + "ms"); 
> var start = new Date; f(); var end = new Date; print("3rd: " + (end - start)
> + "ms"); 
> var start = new Date; f(); var end = new Date; print("4th: " + (end - start)
> + "ms"); 
> var start = new Date; f(1,2); var end = new Date; print("5th: " + (end -
> start) + "ms"); 
> var start = new Date; f(1); var end = new Date; print("6th: " + (end -
> start) + "ms")
> 
> 
> Produces 
> 
> 1st: 79ms
> 2nd: 410ms
> 3rd: 414ms
> 4th: 411ms
> 5th: 121ms
> 6th: 111ms
> 
> Implying hard failure after the initial excess argument compilation.

I'm not sure I see a bug here.

This probably has nothing to do with the number of passed arguments.

In the first call to f() you pass an integer for j.

In the second, third, and fourth calls you pass undefined for j.  Let's make sure we're clear on this.  This most likely has nothing to do with the number of arguments passed.  Passing undefined directly in those calls will likely have the same results.

The fifth and sixth calls to f() pass integers again.  This will now run slower than the first time, since the second, third, and fourth calls probably caused us to recompile f() with j being inferred to be something other than integer.  So, the fifth and sixth calls run at a decent speed (because integers) but not as fast as they could (because type inference stopped assuming that j will be an integer).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160316/1490d597/attachment.html>