WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
98691
Perf. test results page is broken when runs have different sets of tests
https://bugs.webkit.org/show_bug.cgi?id=98691
Summary
Perf. test results page is broken when runs have different sets of tests
Ryosuke Niwa
Reported
2012-10-08 14:50:10 PDT
Perf. test results page is broken when runs have different sets of tests
Attachments
Patch
(5.66 KB, patch)
2012-10-08 14:53 PDT
,
Ryosuke Niwa
no flags
Details
Formatted Diff
Diff
Sample output
(35.54 KB, text/html)
2012-10-08 15:26 PDT
,
Ryosuke Niwa
no flags
Details
Patch
(6.08 KB, patch)
2012-10-08 15:28 PDT
,
Ryosuke Niwa
dbates
: review+
Details
Formatted Diff
Diff
Sample output 2
(35.54 KB, text/html)
2012-10-08 15:29 PDT
,
Ryosuke Niwa
no flags
Details
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2012-10-08 14:53:17 PDT
Created
attachment 167623
[details]
Patch
Ryosuke Niwa
Comment 2
2012-10-08 15:26:47 PDT
Created
attachment 167628
[details]
Sample output
Ryosuke Niwa
Comment 3
2012-10-08 15:28:41 PDT
Created
attachment 167629
[details]
Patch
Ryosuke Niwa
Comment 4
2012-10-08 15:29:15 PDT
Created
attachment 167630
[details]
Sample output 2
Daniel Bates
Comment 5
2012-10-08 16:18:27 PDT
Comment on
attachment 167629
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=167629&action=review
> PerformanceTests/ChangeLog:11 > + Also fix regressions from the previous patch that broke the reference run switch > + and that results page fails to load js files on the remote server.
This sentence does not read well. I take it that these regressions are related closely enough to the test results page being broken with runs that have different sets of tests that it makes sense to fix all these issues in the same patch.
> PerformanceTests/resources/results-template.html:496 > + while (runs[runIndex] !== results[i].run() && runIndex < runs.length)
Without loss of generality, take runs.length := 0. Then we access runs[0], which is outside the array bounds. I suggest reversing the order of the conjuncts here such that we check that runIndex < runs.length before accessing runs[runIndex]. Although accessing an array element whose index is outside the bounds of the array returns undefined in JavaScript, it's good practice to ensure that we're within the array bounds before accessing an array element. A side benefit of this change is that we avoid a comparison and a call to results[i].run() (which I haven't verified whether it has side effects (*)). (*) Can you save me some time, does calling results[i].run() have side effects? If I have a moment, I'll take a look at the code. If it doesn't have side effects then I suggest we cache it so that we don't recompute it on each while-loop iteration.
Ryosuke Niwa
Comment 6
2012-10-08 17:29:54 PDT
Comment on
attachment 167629
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=167629&action=review
>> PerformanceTests/resources/results-template.html:496 >> + while (runs[runIndex] !== results[i].run() && runIndex < runs.length) > > Without loss of generality, take runs.length := 0. Then we access runs[0], which is outside the array bounds. > > I suggest reversing the order of the conjuncts here such that we check that runIndex < runs.length before accessing runs[runIndex]. Although accessing an array element whose index is outside the bounds of the array returns undefined in JavaScript, it's good practice to ensure that we're within the array bounds before accessing an array element. A side benefit of this change is that we avoid a comparison and a call to results[i].run() (which I haven't verified whether it has side effects (*)). > > (*) Can you save me some time, does calling results[i].run() have side effects? If I have a moment, I'll take a look at the code. If it doesn't have side effects then I suggest we cache it so that we don't recompute it on each while-loop iteration.
Sure. I can reverse the order. run() doesn't have a side effect but there probably isn't a need to cache either because it's defined as: this.run = function () { return associatedRun; }
Daniel Bates
Comment 7
2012-10-08 18:18:51 PDT
Comment on
attachment 167629
[details]
Patch This patch looks sane to me.
Daniel Bates
Comment 8
2012-10-08 18:24:04 PDT
Comment on
attachment 167629
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=167629&action=review
> PerformanceTests/resources/results-template.html:499 > + if (runIndex == referenceIndex) > + referenceResult = results[i];
Is this intended? In particular, consider when runIndex, referenceIndex := runs.length.
Ryosuke Niwa
Comment 9
2012-10-08 18:28:06 PDT
(In reply to
comment #8
)
> (From update of
attachment 167629
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=167629&action=review
> > > PerformanceTests/resources/results-template.html:499 > > + if (runIndex == referenceIndex) > > + referenceResult = results[i]; > > Is this intended? In particular, consider when runIndex, referenceIndex := runs.length.
Yeah, that's fine because then results[i] will be undefined in that case.
Ryosuke Niwa
Comment 10
2012-10-08 18:42:53 PDT
Committed
r130711
: <
http://trac.webkit.org/changeset/130711
>
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