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.
[200509041800, jdk1.5.0] Invocation of popup menu on Servlet nodes is slow, it takes: from 500 to 950ms for 1ts usage [limit is 200ms] from 130 to 270ms for subsequent usage [limit is 100ms]. Average values: RHE Linux 3 Solaris 9 WinXP 1st usage 943 ms 809 ms 500 ms Subsequent usage 133 ms 224 ms 273 ms See: http://xtest-db.czech/WebPerformanceDashboard/atomicResult.jsp?buildNumber=200509041800&suiteName=Node%20Popup%20Menus&resultName=Servlet%20node%20popup%20in%20Projects%20View
Reassigning to Marek. Martin, can you please attach the values for regular Java files, so we can compare? Thanks.
Java node popup times are ~ 950/145ms so they are the same as for servlets DO. There isn't any special bussiness which would make the servlet slower than plain java class. Martine plese make this issue as duplicate of appropriate java issue.
reassigning -> see my previous comments
Tondo, I would like to ask you for evaluation of this bug. Please try to find when was this regression introduced. (I hope you have enough information in your databases). At least can anyone attach results for other nodes? E.g. for .txt node or for .properties node? I doubt, that the regression is in java module - we did not do any significant modification in this area AFAIK. Thanks
Here are results you are asking for: Linux FC 3 JDS 3 Solaris 9 Solaris 10 Win 2000 Win XP txt node popup : 84 101 109 98 67 83 properties node popup : 199 176 254 272 93 151 I'ld find the history the value, but I am not sure it's still available. We did some cleaning of old measured values few weeks ago ;(
The numbers you attached is the 1st usage or subsequent usage? Thanks
I am going to attach graph of the measured values (last 80 measurements) for Java file node popup in Projects View Values rises between builds: 200508081800 and 200508211800 It looks like every build the measured value rised for some delta. At the end it was 3-times longer !
Created attachment 25236 [details] 1st usage of Java file node popup menu in projects view
One of the first regression is in 200508091800. According to changelog the biggest change is replacement of VCS support. It might or might not be related.
Frequent evaluating of newTypes is one of problems
Especially for the first usage there is a problem with RMSJavaDOAction.createContextAwareAction that queries GlobalPathRegistry whether the source is registered here.
OK, play it again, Sam. 65549 is fixed.
From results, it does not seem that fix of #65549 has perceptible effect.
First usage should be improved using warmup again. Checking in JavaWarmUpTask.java; /shared/data/ccvs/repository/java/src/org/netbeans/modules/java/JavaWarmUpTask.java,v <-- JavaWarmUpTask.java new revision: 1.10; previous revision: 1.9 done
Please add fresh perf. numbers. Thanks
Here are the results for NB 5.0 (200511061800), JDK 1.5.0_5: ( Linux FC 3 JDS 3 Solaris 9 Solaris 10 Win 2000 Win XP ) Java file node popup in Projects View 1st usage 797 1015 657 528 895 947 2nd usage 121 120 142 132 90 104 Jsp file node popup in Projects View 1st usage 411 397 232 222 166 166 2nd usage 101 102 123 115 68 85 Properties file node popup in Projects View 1st usage 144 158 194 195 104 114 2nd usage 86 96 100 96 50 56 Txt file node popup in Projects View 1st usage 115 97 135 124 78 83 2nd usage 69 73 89 85 31 31
Few more observation from profiler when looking at 1st usage using build from Nov 13): The biggest contributors are: - CVS called from FileSystemAction that computes whole submenu (can be better a bit after fixed caching of context). still the problem is that we compute too much here. - properties action enabling causes creating of SheetSet for Java node (#68299), this is less important for subsequent usages - computing of new types. however we cache the result in the action it takes long time to find source level for the Java node Other contributions: - tools action usualy falls into junittest enabling and thus asks for source group - various lookup sensitive actions defined mostly in project support - construction of menu - show/paint - GC can happen given the number of activities that we perform
OK, Radime. It looks like hardly any improvement can be done in java module. What about reassign this issue to proper modules?
> computing of new types. however we cache the result in the action it takes > long time to find source level for the Java node Not sure if we can do anything in this area. Only what we can do is not to call SourceLevelQuery.getSourceLevel(source) in JavaNode.getNewTypes(), but this will probably be source of quality bugs (non-existing templates on 1.4 or missing templates on 1.5). I will attach some time consumption data forSourceLevelQuery.getSourceLevel(source) later. I'm not sure if projects team will be able to optimize this call. (Bear in mind that only first invocation is slow, next one is fast enough.) > properties action enabling causes creating of SheetSet for Java node (#68299), > this is less important for subsequent usages This was already fixed by Jirka, we should wait to new data to look for performance gain. > CVS called from FileSystemAction that computes whole submenu (can be better a > bit after fixed caching of context). still the problem is that we compute too > much here. I do not know if CVS team investigates anything in this area. As they are probably last team which can do something for 5.0, reassigning this to them for further evaluation.
At CVS side menus are created lazily on setSelected(). Returnimg to performance team to verify actual issue state.
Last numbers (Pentium III 800MHz, 384MB) Java file node popup in Projects View: 249 250 253 260 258
Recent integrations (e.g. Petr Kuzel's CVS lazy presenter, Jirka Rechatecek's Properties action enablement) improved the times here. Today's numbers are: Java file node popup in Projects View [ ms ] / 100 ms FC3 Sol9 Sol10 W2K WinXP 1st usage 139 163 164 104 140 Subsequent usage 101 114 110 67 70 Marking as fixed.
Thanks to everyone, it has been really improved. verified in NB 5.0 (200511281900)