Community
Participate
Working Groups
Sorry if this is a dup, but I couldn't find any open bugs on this topic. JSP validation performance is way better than earlier milestones, so please don't think I'm trying to get down on you. Thanks for all the work that has already been done. However, JSP validation of small/empty files is still an order of magnitude slower than Java compilation. I've been trying to fix some scalability bugs lately, and building up a Web project with 1000+ JSP files is painful. Although we can now process several files per second, even pasting in a directory with this many empty JSP files causes an extremely long build.
We'll approach this problem first by getting some good use caes, and find out where the time goes ... sepcially when compared with Java!
I put in some simple timing/print statements to see where the bottlenecks were. It looks like JSPTranslation#reconcileCompilationUnit() takes the most time for validation (as expected). In that method we're doing a CU.makeConsistant(), and right after we do a CU.reconcile() call. We might not need the "makeConsistant()" call, which takes a good amount of the time in that method. I've got to investigate a little more. In fact, the javadoc says: Note: Using this functionality on a working copy will interfere with any * subsequent reconciling operation. Indeed, the next {@link ICompilationUnit#reconcile} * operation will not account for changes which occurred before an * explicit use of {@link #makeConsistent(IProgressMonitor)} which is exactly what we're doing...
I don't know the code, but even a couple of edge-case optimizations would help, e.g. don't validate empty files or anything obviously broken. In my cases the files have been either empty or very simple, so it seems like we could make some optimizations here that we couldn't with larger or more complex JSP files.
Mass transfer from pa to dw. Needs more triage.
performance bugs should use performance keyword (not [performance] in subject).
Aaaa, another JSPTranslation#reconcileCompilationUnit() bug. The description is right, there are many bugs open about this problem. The best that can be done on this front is that Bug 299423 will cause JSPTranslations to be persisted to disk so that this expensive call does not have to be made unless a JSP file changes or of course on the first add. There is no way around the fact that the JSP documents need to be translated for indexing though and the first time through is going to have to have this call, and any changes to the JSP documents. Though #makeConsistent(IProgressMonitor) is still in use with #reconcile so it would be worth looking into if the #makeConsistent call is needed.
*** Bug 158637 has been marked as a duplicate of this bug. ***
As Ian mentioned, a lot of work has gone in to making sure translations are only performed when necessary. In addition to this, I've cleaned up the use of makeConsistent as this seems largely unnecessary. Ad hoc testing as well as unit tests have all gone well.
