WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
95668
Performance test should support asynchronous tests
https://bugs.webkit.org/show_bug.cgi?id=95668
Summary
Performance test should support asynchronous tests
Taiju Tsuiki
Reported
2012-09-02 23:55:25 PDT
Most of storage related APIs are asynchronous. So, we need asynchronous test support to test them.
Attachments
Patch
(4.28 KB, patch)
2012-09-03 18:43 PDT
,
Taiju Tsuiki
no flags
Details
Formatted Diff
Diff
Drop runAsync
(3.04 KB, patch)
2012-09-13 21:58 PDT
,
Taiju Tsuiki
no flags
Details
Formatted Diff
Diff
add test, merge runPerSecond to async version
(6.09 KB, patch)
2012-09-14 09:33 PDT
,
Taiju Tsuiki
no flags
Details
Formatted Diff
Diff
Convert Animation/balls to use PerfTestRunner.measureValueAsync
(5.05 KB, patch)
2012-10-17 13:37 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Convert Animation/balls to use PerfTestRunner.measureValueAsync
(5.05 KB, patch)
2012-10-17 13:42 PDT
,
Ryosuke Niwa
dpranke
: review+
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Taiju Tsuiki
Comment 1
2012-09-03 18:43:57 PDT
Created
attachment 161954
[details]
Patch
Ryosuke Niwa
Comment 2
2012-09-11 12:13:08 PDT
Comment on
attachment 161954
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=161954&action=review
> PerformanceTests/ChangeLog:9 > + Test function for the runAsync and runPerSecondAsync should invoke
Do we really need both runAsync and runPerSecondAsync?
Taiju Tsuiki
Comment 3
2012-09-12 02:38:44 PDT
(In reply to
comment #2
)
> (From update of
attachment 161954
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=161954&action=review
> > > PerformanceTests/ChangeLog:9 > > + Test function for the runAsync and runPerSecondAsync should invoke > > Do we really need both runAsync and runPerSecondAsync?
Actually, I don't need runAsync. Adding runAsync corresponding to run looked cleaner to me. Should I drop runAsync?
Ryosuke Niwa
Comment 4
2012-09-13 10:27:39 PDT
I'd prefer just adding either one as a part of the
bug 95704
since we don't normally add unused code.
Taiju Tsuiki
Comment 5
2012-09-13 21:58:32 PDT
Created
attachment 164046
[details]
Drop runAsync
Taiju Tsuiki
Comment 6
2012-09-13 22:00:24 PDT
(In reply to
comment #4
)
> I'd prefer just adding either one as a part of the
bug 95704
since we don't normally add unused code.
Done. I dropped runAsync. Could you take a look again?
Ryosuke Niwa
Comment 7
2012-09-13 22:14:11 PDT
Comment on
attachment 164046
[details]
Drop runAsync View in context:
https://bugs.webkit.org/attachment.cgi?id=164046&action=review
> PerformanceTests/resources/runner.js:276 > + this._doneFunction = function () { if (test.done) test.done(); }; > + this._description = test.description || ""; > + this._runCount = test.runCount || 20; > + this._callsPerIteration = 1; > + this.unit = 'runs/s'; > + > + this._test = test; > + this._runner = this._perSecondAsyncRunner; > + this.initAndStartLoop();
We shouldn't have to duplicate all this code.
> PerformanceTests/resources/runner.js:281 > + var timeToRun = this._test.timeToRun || 750;
Is 750ms really long enough for async tests? How many runs per second do we typically get? Anything below 100 runs/s is statistically unsound. On the other hand, at 100 runs/s, each run is only 10ms at which point we have to worry about the time spent in context switch, etc...
> PerformanceTests/resources/runner.js:305 > + self._test.run(nextIteration.bind(window, j + 1));
It's not clear to me how this "run" function is used. I would really like to see this patch being merged with the one that adds an actual test. Also, we need to be careful with calling functions like "bind". It may affect V8 behavior in subtle ways.
> PerformanceTests/resources/runner.js:310 > + totalTime += Date.now() - startTime; > + i += callsPerIteration; > + if (self._completedRuns < 0 && totalTime < 100) > + callsPerIteration = Math.max(10, 2 * callsPerIteration);
How slow is async function call here? If an async benchmark actually requires a context switch between two threads, then 100ms is probably not long enough.
Taiju Tsuiki
Comment 8
2012-09-14 09:33:42 PDT
Created
attachment 164169
[details]
add test, merge runPerSecond to async version
Taiju Tsuiki
Comment 9
2012-09-14 09:34:13 PDT
Comment on
attachment 164046
[details]
Drop runAsync View in context:
https://bugs.webkit.org/attachment.cgi?id=164046&action=review
>> PerformanceTests/resources/runner.js:276 >> + this.initAndStartLoop(); > > We shouldn't have to duplicate all this code.
I merged runPerSecond to runPerSecondAsync.
>> PerformanceTests/resources/runner.js:281 >> + var timeToRun = this._test.timeToRun || 750; > > Is 750ms really long enough for async tests? > How many runs per second do we typically get? Anything below 100 runs/s is statistically unsound. > On the other hand, at 100 runs/s, each run is only 10ms at which point we have to worry about the time spent in context switch, etc...
For simple filesystem test like creating file or write small data to a file, it runs around 3500 times/sec on DumpRenderTree and over 1000 times/sec on Chrome. I think it's enough.
>> PerformanceTests/resources/runner.js:305 >> + self._test.run(nextIteration.bind(window, j + 1)); > > It's not clear to me how this "run" function is used. I would really like to see this patch being merged with the one that adds an actual test. > > Also, we need to be careful with calling functions like "bind". It may affect V8 behavior in subtle ways.
I see. I'll merge another change to this. I don't know how much time bind() need... Can we use anonymous function safely instead?
>> PerformanceTests/resources/runner.js:310 >> + callsPerIteration = Math.max(10, 2 * callsPerIteration); > > How slow is async function call here? If an async benchmark actually requires a context switch between two threads, then 100ms is probably not long enough.
My tests is enough fast, at least, even when it needs IPC round trip. If some test needs more time, it might need to be configurable.
Ryosuke Niwa
Comment 10
2012-09-14 14:44:53 PDT
(In reply to
comment #9
)
> For simple filesystem test like creating file or write small data to a file, it runs around 3500 times/sec on DumpRenderTree and over 1000 times/sec on Chrome. I think it's enough.
Okay.
> I see. I'll merge another change to this. > > I don't know how much time bind() need... Can we use anonymous function safely instead?
Ideally, the code that runs between each run is as small/fast as possible. In general, anything that non-trivial like creating new array, accessing a DOM node, creating an anonymous function, etc... should be avoided as much as possible. On the other hand, things like integer arithmetics should be fast and probably won't affect the js heap.
> My tests is enough fast, at least, even when it needs IPC round trip. > If some test needs more time, it might need to be configurable.
Okay.
Ryosuke Niwa
Comment 11
2012-10-08 15:55:07 PDT
Comment on
attachment 164169
[details]
add test, merge runPerSecond to async version Ugh... this is very outdated now. Please upload a new patch that applies to ToT.
Ryosuke Niwa
Comment 12
2012-10-17 13:37:45 PDT
Created
attachment 169247
[details]
Convert Animation/balls to use PerfTestRunner.measureValueAsync
Ryosuke Niwa
Comment 13
2012-10-17 13:42:56 PDT
Created
attachment 169250
[details]
Convert Animation/balls to use PerfTestRunner.measureValueAsync
Ryosuke Niwa
Comment 14
2012-10-17 13:57:40 PDT
Committed
r131638
: <
http://trac.webkit.org/changeset/131638
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug