This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[jdk1.5.0](rc) our performance tests show regression in first opening java file between buids (200409051800 - 200409022120) : test : Open Java file (20kB) (RH Linux 9 JDS 2 Solaris 9 Win 2000 Win XP) *200409051800* 1st usage 6205 6630 8352 5036 5922 2nd usage 526 520 661 395 499 *200409022120* 1st usage 3037 3058 2469 1599 1911 2nd usage 534 523 641 393 503 *200409011800* 1st usage 2452 3049 2304 1651 1984 2nd usage 543 513 668 378 478 Numbers above show 2-3 times slower open java file in last dev build against previous one.
Probably caused by : Modified: src/org/netbeans/modules/java JavaEditor.java JavaDataObject.java Log: Parsing support initialized when JavaEditor is opened Revision Changes Path 1.175 +6 -0 java/src/org/netbeans/modules/java/JavaEditor.java
Pavel will try to reproduce it.
Hopefully fixed. Tested on my machine and seems it works correctly now. Checking in org/netbeans/modules/java/JavaNode.java; /cvs/java/src/org/netbeans/modules/java/JavaNode.java,v <-- JavaNode.java new revision: 1.118; previous revision: 1.117 done
Thanks Pavel, it's much better now: *200409071800* 1st usage 4025 3205 3006 1505 2489 2nd usage 475 498 657 393 490 but there is still regression Lin 30%, JDS 8%, Sol 5%, Win2K -1%, WinXP 25% wait for tomorrow results, if regression still measured I'll file new issue. significant improvement - verified
Keeping opened until we verify by the test results that this is not regression. Until then, this is considered as beta-2 showstopper.
Today's numbers show still existing regression (or/and variation of measured values grows): *200409081800* 1st usage 3509 3286 4184 1510 2739 2nd usage 488 503 660 404 468
When fixed it will have to be merged to release40_beta2 branch.
We tried to investigate it again with Radim and we did not find anything in Java module, which should cause this regression. Radim pointed out one thing, which can cause the problem: There was running full gc() during open file. I made a small test to ensure that there is a different count of gc() in builds. My testcase: 1. Start ide, 2. open form project, 3. find GandalfPersistenceManager in explorer, 4. use jstat to get the count of FGC, (thanks Radim for info about jstat utility) 5. open GandalfPersistenceManager, 6. get the count of FGC again. nb200409022120 - FGC before: 15; FGC after: 15 nb200409051800 - FGC before: 14; FGC after: 15 So seems to me that in newer build, anybody save some memory and one full gc() was done during opening file instead of before. (Not sure, how data is exactly purged in perf tests.) Closing as INVALID because I suppose data is not purged. Reopen, if my explanation is not applicable to perf test.
As Marian mentioned, there was done fix before reopening this bug, so it should be marked as fixed.
Fixed on 2004-09-07.
Thanks, verified on 2004-09-09 . There is still a regression, but we don't know how to fix it so verified.
Created attachment 17637 [details] changelog
Reopening as P2. I don't think it's ok to say "there used to be no FGC, now there's one, so it must take longer". The regression is real and it needs to be investigated. I'm not saying that this is a java module issue, but with the full list of changes at hand, we should be able to identify the one that triggerred this.
Performance guys, please evaluate. Performance bug is, that we saved 1 FGC on startup, which is now postponed to first opening of java file.
First of all, tests should be improve to show real regressions.
Old issue. File opening will be filed as new issues for promo-F as appropriate.
v/c