Community
Participate
Working Groups
Created attachment 164080 [details] profile We have a workspace with ~80 Dynamic Web Projects and ~40 EJB Projects. We've noticed since 3.6 that our JSP Validation is taking significantly longer (JSPDirectiveValidator#performValidation used to take about 15.5s and it's now taking about 254.7s). I've included the portion of the Yourkit profile that I think might be of assistance (if you need the whole file, please let me know). But what I found is that it looks like JavaProject#getResolvedClasspath(boolean) is taking 251.5s where it only used to take about 12s before for the same number of invocations. Thanks.
Jay, please investigate.
Note that we need to check if each manifest has referenced jars, but I don't think this should take so long.
(In reply to comment #0) > Created an attachment (id=164080) [details] > profile > > We have a workspace with ~80 Dynamic Web Projects and ~40 EJB Projects. We've > noticed since 3.6 that our JSP Validation is taking significantly longer > (JSPDirectiveValidator#performValidation used to take about 15.5s and it's now > taking about 254.7s). Would it be possible to attach the pre-3.6 profiling data, if you still have them at hand. In fact, complete profiling file for both before and after 3.6 would help. Looking at the attachment, ClasspathEntry#resolvedChainedLibraries and ClasspathEntry#getCalledFileNames are taking majority of the time. Interestingly nothing big has changed in those methods in 3.6. Could you please confirm that the test case and test projects have not changed between runs?
Thanks for the snapshots, Nick. This is what I found after a close look at them - most of the time used by the concerned methods seems to be spent in JAR file read operations. For instance, three invocation of java.util.zip.ZipFile.<init>(File) takes 101,765, 28,750 and 14,656 ms respectively. Also, looking at org.eclipse.jdt.internal.core.ExternalFoldersManager.isExternalFolderPath(IPath), most of the 21,906 ms is spent in file operations. Just wondering if anything has changed in the test files or the environment.
Hey Jay, Nothing's changed as far as I can tell. Is there something in particular I could look out for or might be indicative of an increase in time spent in file operations?
So, according to Nick, there may have been quite a few number of web app containers in the test environment. The delay seem to be in resolving the referenced JAR entries contained by the web container. As stated in bug 305037, we don't want to resolve the chained (referenced) library entries that come from the container. That should address this particular performance issue. It remains to be discussed whether we want to make the resolution of referenced libraries an optional feature by proving a preference setting.
As stated in comment #6, this should be taken care of by the fix to bug 305037. Nick, if you see this problem with build I20100420-0800 or later, please reopen the bug.
(In reply to comment #7) > As stated in comment #6, this should be taken care of by the fix to bug 305037. > Nick, if you see this problem with build I20100420-0800 or later, please reopen > the bug. Thanks for your investigation, Jay! I'll be sure to verify.
Though I cannot verify by running, some of the calls that were shown up in the profile are removed and hence, I believe the performance should be better. Verified for 3.6M7 using build I20100424-2000
Verified.
