Community
Participate
Working Groups
Generation of performance tests results made many queries to database to get values which can be improved by introducing a better model to get and store database information. Currently all data get from database are stored on local maps and the information is asked again for each generated files: fingerprints, status table, graphs and raw data. The idea would be to have results objects used to read and store data at the beginning of the generation and provide the necessary values while building each needed files.
Increase severity to major because this improvement will also make the maintenance and change of this code easier and safer (hopefully)...
Created attachment 77232 [details] Proposed patch The patch was too big to be attached as patch file (282Kb), so it has been zipped. Short summary of what this patch do: 1) Introduce a new model in org.eclipse.test.performance project for results 2) Rewrite classes generating files in org.eclipse.test.performance.ui project to use the new results model and avoid unnecessary multiple database queries 3) Add comments in the code to make it easier to maintain and evolve 4) Include fixes for bug 186549 and bug 198957
The first interesting effect of the proposed change is that it speeds up generation. The first measures I did while playing with was 6 times faster, but it was a little time ago and I'll redo some measures to be a bit more precise...
I got the time with proposed patch; it took 46 minutes to generate the perf results. With current org.eclipse.test.performance.ui version, generate the same results took more than 150 minutes (2h30). So, in fact it's less than I initially thought: more than 3 times faster... :-( But I think it's a good starting point... :-)
Created attachment 77470 [details] Proposed patch without fix for bug 186549 Finally there were so many ways to fix bug 186549 that I preferred put it out of the patch for this bug. This new patch also fixes some minor issues I discovered since the previous posted patch... Note that this new patch still fixes bug 198957.
Sorry, last patch still fixes bug 186549! I was confused by another remaining issue: how to display fingerprint for test with no error ([n/a]: when only one measure was done)...
(In reply to comment #6) > Sorry, last patch still fixes bug 186549! > > I was confused by another remaining issue: how to display fingerprint for test > with no error ([n/a]: when only one measure was done)... > I've opened bug 201920 to address this issue.
Created attachment 77485 [details] New patch without fix for bug 186549 I think I need some vacations as the previous patch finally didn't not fix bug 186549!!! So, I re-run generation on this new one and I confirm that bug 186549 will not be fixed while fixing this bug! Definitely sorry for all this confusion... :-( However, I has to attach a new patch because I discovered some minor regressions introduced while splitting fixes... This is now OK and this patch is the latest ultimate version ready to be released!
Created attachment 80768 [details] Ultimate patch (version 7) Previous patch + incremental generation. To avoid asking all data from the beginning to the releng database, already generated builds numbers are stored locally if -dataDir argument is specified in command line. This will make time to generate approximately the same whenever the generation is done in the eclipse cycle although time increased exponentially at the end of the release with previous version...
Released for 3.4M3 in HEAD stream.
Here are times I got on my test box (Windows Vista - Intel Dual Core 6600 (2.4GHz) - 3Go RAM) to generate results for N20071015-0010: - 80 minutes before patch - <10 minutes after patch without using incremental generation - <6 minutes after patch using results of N20071004-0010 Note that I was also able to generate results for I20071016-0800 from remote releng database using N20071015-0010 results in around 45 minutes. I was never able to generate results from remote database before as it took too much time...
Patch released in R3_3_maintenance stream
