Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 454147

Summary:	A number of "performance test links" need fixing or improvements
Product:	[Eclipse Project] Platform	Reporter:	David Williams <david_williams>
Component:	Releng	Assignee:	David Williams <david_williams>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	4.4
Target Milestone:	4.5 M4
Hardware:	PC
OS:	Linux
Whiteboard:
Bug Depends on:
Bug Blocks:	374441

Description David Williams

2014-12-04 10:57:59 EST

There's several cases where the links are "just wrong" ... simply as a function of slight changes in "layout" of results. I'll try to capture (and fix) them via this bugzilla. 

FWIW, I think the original assumption, years ago, was that the "main page", "perforamnce.php" was in same directory as performance results .../performance, whereas now, it is "one up" from performance directory. 

I've looked at moving performance.php "down" a level, but seems to me to be about the same amount of work ... but, probably deserve closer insspection. 

One place to fix links is in "global_fp.php". That's because they are read in and "included" in performance.php, essentially moving their "base directory" up one level that what they expect. 

The way I fixed this "by hand" was to define
<?php
$performanceDir="performance";
?>
at top of file, and then adding that variable to links, where it mattered, such as in 

echo '<img src="'.$performanceDir.'/FP_R-4.4_N20141203-2000.linux.gtk.x86_64.gif" usemap="#FP_R-4.4_N20141203-2000.linux.gtk.x86_64" name="linux.gtk.x86_64">';
echo '<map name="FP_R-4.4_N20141203-2000.linux.gtk.x86_64">';
echo '<area shape="RECT" coords="0,5,1000,23" href="'.$performanceDir.'/linux.gtk.x86_64/Scenario5.html">';

Kind of awkward.

Comment 1 David Williams

2014-12-04 11:02:03 EST

another link, is the "back to global results" link. 

For example, if I drill down into "jface" results, 

http://download.eclipse.org/eclipse/downloads/drops4/N20141203-2000/performance/org.eclipse.jface.php?fp_type=0

It's "back to global results" link points to 

http://download.eclipse.org/eclipse/downloads/drops4/N20141203-2000/performance/performance.php?fp_type=0

instead of 

http://download.eclipse.org/eclipse/downloads/drops4/N20141203-2000/performance.php?fp_type=0

Comment 2 David Williams

2014-12-04 11:05:43 EST

Another place that need improvement is that when we run the "short set" of tests (such as for "nightly" builds) then there are *always* links for 

org.eclipse.jdt.core*
org.eclipse.jdt.text*

even though they have no results for "short tests". 
In other places in code, we look for the existence of some file, before displaying a link to it. In this case, we might still want to display something ... to signify they were not expected, not just "failed to run", but, a "link to no data" is very confusing. Definitely looks like something is wrong.

Comment 3 David Williams

2014-12-08 00:51:08 EST

I think (just now) have fixed these in Git. 

Some still broken in initial N20141206-2000 (and I20141207-2000 once tests complete) that caused performance page to not display ... fixed by N-build by hand, and will fix I-build by hand once tests are done (else, hand fixes will be over written). 

But I think 1208-0800 build should be correct "out of the box". Will re-open if I find spots I missed. 

FWIW, this fix also included general "clean up" and XHTML compliance of "log files". Also, if the three "log file displays" that we have (normal unit tests, unit tests from performance run, and unit tests from baseline run) I "factored out" a sizable chunck of common PHP code into "logPhpUtils.php".

Comment 4 David Williams

2014-12-08 00:55:42 EST

(In reply to David Williams from comment #0)
> FWIW, I think the original assumption, years ago, was that the "main page",
> "perforamnce.php" was in same directory as performance results
> .../performance, whereas now, it is "one up" from performance directory. 
> 
> I've looked at moving performance.php "down" a level, but seems to me to be
> about the same amount of work ... but, probably deserve closer insspection. 
> 

Should have mentioned ... the main part of the fix WAS to put performance.php down a level, into .../performance/ 

It did turn out to be fewer changes, but mostly just "cleaner".

Comment 5 David Williams

2014-12-08 01:10:29 EST

Well, that was a fast "reopening" but found a problem already. 

On the main performance test page, I put the "junits" from that run (to see "pass/fail" table). 

And, the links in there are wrong. They "point to" results in /.../performance/performance/... (which, are not there) instead of just .../performance/....

Comment 6 David Williams

2014-12-08 15:16:48 EST

(In reply to David Williams from comment #5)
> Well, that was a fast "reopening" but found a problem already. 
> 
> On the main performance test page, I put the "junits" from that run (to see
> "pass/fail" table). 
> 
> And, the links in there are wrong. They "point to" results in
> /.../performance/performance/... (which, are not there) instead of just
> .../performance/....

I think I can fix this "junit table" problem by passing in "." to our custom ant task that computes the summary tables ... and am trying a test build with that now. 

Not sure I mentioned this before, but another place of error was that 'console logs' had to link "one up" in the hierarchy to find the right file ... not sure that will work quite right ... am investigating now. 

Similarly, the "baseline" junit results were not being displayed/linked to since it also has to point "one up" in the directory structure. That seems to work ok.

Comment 7 David Williams

2014-12-09 11:17:02 EST

Using the "." value appeared to work fine in my local test run, so committed that change ... in time for the Tuesday 11:15 I-build. (along with other, "less risky" ones).