Closed Bug 214139 Opened 21 years ago Closed 16 years ago

setTimeout(fun) slower than setTimeout("fun()")

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: markushuebner, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

This bug is based upon comment #7 in bug 212831 From that bug: ----- 2) Things like setTimeout("callFunction()", 1) are guaranteed to be slower than things like setTimeout(callFunction, 1). In light of these two items, the incredible JS overhead I was seeing in the profile makes perfect sense -- the page is running a bunch of JS that has nothing to do with anything and doing so in the slowest way it can. Especially: you are re-invoking the JS compiler to recompile bytecode for "callFunction();" on every setTimeout. ----- There are some testcases: http://basic.mozillanews.org/timeout-test_complex.html http://www.world-direct.com/mozilla/moz-timeout-tests/ There are quite strange things happening: In http://www.world-direct.com/mozilla/moz-timeout-tests/timeout- test_short.html the suggested method [calling new method] is even slower! (old method: 3535ms / new method 4196ms) http://basic.mozillanews.org/timeout-test_short2.html is self running and after the first run the results steadily aligning.
Reassigning -
Assignee: rogerl → khanson
Here is Brendan's comment from that same bug: ------- Additional Comment_#8 From Brendan Eich 2003-07-23 10:35 ------- bz's right. Point 2 especially: you are re-invoking the JS compiler to recompile bytecode for "callFunction();" on every setTimeout. Use the funarg force, Luke. /be ------------------------------------------------------------------------- So my question is, what is the bug here? That setTimeout() should not re-invoke the JS compiler to recompile bytecode? Is that what you are saying? Can you say more about what you think is going wrong? Thanks -
Sorry for not being more precise. What this bug is about is that setTimeout(function,1) should be faster than setTimeout("function()",1). In the testcase at http://www.world-direct.com/mozilla/moz-timeout- tests/timeout-test_short.html for example though it's even slower!!
Markus: thanks! If you have time, could you post some of the timings here, including a comparison with IE's performance on this? Since the DOM is involved (setTimeout() is a DOM function), this may be a DOM bug instead of JS Engine per se.
well it isn't really slower just that it isn't faster. From some of the testing we (matic & me) were doing we found that depending on which method is used first, most of the time the first method we do the test would be faster. I'm not sure if this is due to the calling of the function that does the second method at the end of the test of of the first method (stack issues?).
Here are my results: http://www.world-direct.com/mozilla/moz-timeout-tests/timeout-test_short.html trunk 20030724004 - old: 3956 / new: 4907 msie6 - old: 2994 / new: 10 http://www.world-direct.com/mozilla/moz-timeout-tests/timeout-test_complex.html trunk 20030724004 - old: 21992 / new: 22342 msie6 - old: 3205 / new: 20
The compiler can't be slower when it isn't run at all. Perhaps the GC root allocation and free required for the funobj form is costlier than compiling. I find that hard to believe. /be
Assignee: khanson → dom_bugs
Component: JavaScript Engine → DOM Level 0
Summary: JS compiler is slower when not recompiling bytecode for "callFunction();" on every setTimeout → DOM setTimeout faster or no slower for "callFunction();" vs callFunction
Blocks: 118933
Setting default QA -
QA Contact: pschwartau → ashishbhatt
Summary: DOM setTimeout faster or no slower for "callFunction();" vs callFunction → setTimeout(fun) slower than setTimeout("fun()")
On http://www.world-direct.com/mozilla/moz-timeout-tests/timeout-test_short.html I see the "new" method consistently faster, and the CPU usage during the test is 0, so it's not a "perf" issue. On http://www.world-direct.com/mozilla/moz-timeout-tests/timeout-test_complex.html I see one or the other faster in different tests; the results are so noisy that the differences are well below a standard deviation. Is there still a problem here?
Using trunk build 2004022509 on win-xp pro sp1 on testcase http://www.world-direct.com/mozilla/moz-timeout-tests/timeout-test_short.html I constantly get the following results: Old Method: 4016 New Method: 4887 For me too is the very low CPU usage - so removing perf keyword.
Keywords: perf
So perhaps the code at http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#4914 is slower for the function object case? In particular, having to root the arg?
One could comment out the (un)rooting code and disable GC and re-run the tests to find out :-)
Firefox 1.0RC1 Linux Slackware 10 old:3214 new:3253 old:3257 new:3205 Suggesting WFM.
What would be very interesting to know is how jst's suggestion in comment #12 would affect this.
Running the testcase on win-xp pro sp1 with trunk build 2004102604: old:4036 new:4877 old:4897 new:4917 old:4637 new:4667 Running the same on MSIE 6 SP1 old:2994 new:50 old:2995 new:10 old:2994 new:10 So the new method which should be faster (and is extremely faster on MSIE) is acttually slower. So investigating will hopefully bring some more light here.
Just for information: Opera 7.6pv1 on Windows 2000: old:2975 new:2984 old:3014 new:2995 old:2984 new:2964 Opera 7.54 on the same machine: old:4967 new:4937 old:4967 new:4988 old:5057 new:4887 Safari 1.2 / Mac OS X: old:1157 new:624 old:443 new:557 old:434 new:555 Internet Explorer 5.2 / Mac OS X: old:1024 ...then doesn't run further Opera 7.51 / Mac OS X: old:3444 new:3296 old:3680 new:3308 old:3397 new:3294 Regards, Manni
Mozilla 1.8 Alpha 4 @ Windows 2000: old:3585 new:4256 old:4267 new:4216 old:4246
Moz 0.6 (20001205) @ Windows 2000: old:3035 new:2994 old:3024 new:2995 old:3004 Seems there haven't been many changes to this code during the last four years :)
setTimeout(fun, x) is fractionally faster than setTimeout("fun()", x) for me, too, just as expected (Windows XP, Deer Park Alpha 2). As a side note the testcase uses setTimeout in a way that is not supported by IE so you can't compare its results with the other browsers. IE does not pass additonal arguments to setTimeout on to the function, so setTimeout(the2,1,count) is the same as setTimeout(the2,1) and 'if (count<300)' becomes 'if (undefined<300)', which is always false.
Markus, do you actually see any CPU usage here? I certainly don't, and I see the two methods as being equally fast (some tests one comes out ahead, some tests the other does), with lots of noise due to limited timer resolution.
I've run the testcase on Fx3.1 beta, Fx2 2.0.0.14, Safari 3.1.1, with 100 runs. Results in milliseconds Fx3: 884 Safari: 1080 Fx2: 2978 if nobody thinks there's still some improvement margins, IMO this bug can be resolved as WORKSFORME
"the testcase"? And you came out with a single number? This bug is about the fact that the "old" and "new" approach give different numbers with "new" being slower (when it should be faster). It doesn't matter what other UAs are doing here; this bug is about how two different things Gecko does compare to each other.
Mmmhhh... I'm just messing up perf bug reports. Sorry. Ignore completely my previous comment, it was referred for Bug 118933, and anyway I think it's incorrect. Well, I've run some of testcases. I run a testcase 4-5 times reloading it. What I noticed is that sometimes the old method is faster, sometimes the new one is, reloading the _same_ testcase. I think the testcases could be improved doing an average of X runs. What do you think about?
Very likely, yeah. If there is no consistent performance difference, that does sound like this bug is WORKSFORME.
WFM on 2008051806 I am pretty sure 8% is beyond what could be considered negligible (actually a quick T test says the chances of that tends to 0 [1.08516E-27 as calculated by excel]). I would feel very confident in saying the "new" approach is faster than the "old" approach (at least on my machine). old new average 3430.84375 3170.59375 min 3228 3084 max 3566 3247 average % difference: 7.865710024 min % difference: 1.403837155 max % difference: 11.72628767 % difference calculation = (new - old)/((new + old)/2) data: old:3228 new:3183 old:3306 new:3084 old:3464 new:3176 old:3389 new:3106 old:3452 new:3177 old:3458 new:3180 old:3459 new:3185 old:3456 new:3166 old:3464 new:3166 old:3450 new:3176 old:3453 new:3178 old:3303 new:3172 old:3458 new:3178 old:3466 new:3114 old:3458 new:3174 old:3457 new:3174 old:3460 new:3172 old:3467 new:3187 old:3566 new:3171 old:3322 new:3180 old:3462 new:3173 old:3304 new:3181 old:3468 new:3177 old:3465 new:3161 old:3493 new:3178 old:3458 new:3175 old:3460 new:3170 old:3467 new:3164 old:3460 new:3247 old:3455 new:3195 old:3456 new:3166 old:3303 new:3173
Bill, thanks for testing! Does look like this is no longer a problem, indeed.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.