Open
Bug 673614
Opened 13 years ago
Updated 2 years ago
Investigate speeding up /tests/layout/generic/test/test_bug514732.html
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
NEW
People
(Reporter: jgriffin, Unassigned)
References
(Blocks 1 open bug)
Details
As part of the BuildFaster project (see https://wiki.mozilla.org/ReleaseEngineering/BuildFaster), we are investigating whether certain slow mochitests can be sped up. test_bug514732.html is a slow test, average execution time on a recent run (in ms): win32-debug, 31787 linux-opt, 28768 macosx64-debug, 32499 win32-opt, 28822 linux64-opt, 28784 linux64-debug, 32147 macosx-debug, 32645 linux-debug, 32267
Reporter | ||
Comment 1•13 years ago
|
||
Roy, as the original author of this test, would you be willing to help see if the execution time of this test could be improved?
Comment 2•13 years ago
|
||
(In reply to comment #1) This test modifies the page and tests (a) that a specific event is fired when we expect it to be, and (b) that this event is not fired when we expect it not to be. For (b), in order to be sure that an event is not fired, the test waits around for a few seconds before continuing. I'm fairly certain that these waiting periods are what you're measuring when you see that the test is consistently slow. In file_bug514732_helper.html, the JS function waitInterrupt sets this waiting period to 3500 milliseconds (see the argument to setTimeout). I seem to recall thinking that this was a rather inexcusably high value, but that we still brought it up there in order to prevent random oranges at the time. (The waiting period used to be 1200 milliseconds, which isn't that much better.) This change occurs in revision e67094febf72, in response to bug 527872.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•