Bugzilla – Full Text Bug Listing
| Summary: | Import of Symptom Database file is very slow | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Liz Dancy <lizdancy> |
| Component: | TPTP.monitoring | Assignee: | Alex Nan <apnan> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P1 | CC: | gotohy, slavescu, smith |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | closed460 | ||
|
Description
Liz Dancy
Alex, please investigate this. I have done some testings using IBM 5 SR1 and found the following: - if you import a symptom catalog, choose to open the editor and close the editor without switching to the Details tab an exception is recorded in the .log file. This exception prevents the editor from doing all the cleanup and the catalog is kept in memory by an uncleaned reference. If you import several times ( I did it 11 times) the WAS catalog and close the editor memory is increasing linearly and also the import time is increasing linearly but not significanlty. So my performance measurements show that the running time for the first two runs was in the 90 s range then it increased slowly at about to 100 - 120 s and then finally it went up to 180 s. But his is far lees then you reported. - if you import a catalog, open the editor, switch to the details tab and then close the editor memory is released and everything works fine. I did 11 runs for this scenario and the running time was in the 90 s range in 10 out of 11 runs. Memory was always released after I closed the editor. I got a run with a strange 572 s (it was the 5th) which is out of the pattern, but giving the fact that it occured only once in 11 runs I think it's less significant. It looks like what you see is actually a similar result to my 572 s run. I would be curios to see what happens when you run the scenarios that I ran. After re-running without the memory leak, I was able to import in 130s with IBM JRE 50. I ran 11 consecutive imports using IBM JRE 50 SR1. The results showed that of the 11 imports, only two showed anomalous results. One anomalous result was an exceptionally long import and the second was a workbench freeze after an exceptionally long import ( both long imports were between 8 and 10 minutes). The remaining nine tests had import times avergaing about 2.5 minutes. This is not critical problem, it will be investigated in 4.4. Target i3 to retest the scenario with 4.4 i3 based on Eclipse 3.3. I am marking this defect as fixed as I have mode some changes to the import sdb handlers and also to the model (suggested by Yasuhisa - thanks). For now the changes to the model are temporary since we didn't regenerate the model but they are generic and not tight with the import sdb wizard.The import from WAS is not 3 times faster but I have noticed that now the import from symptom 2 is pretty slow compared to symptom 2. Didn't have time to investigate why. Anyway I hope that the issue reported in this defect is solved for good. What I meant to say is that the WAS import is now 3 times faster, at least on my machine. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |