Bugzilla – Full Text Bug Listing
| Summary: | ASTParser.createASTs() performance slowdown in 4.5.2 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Emmanuel Rodriguez <emmanuel.rodriguez> |
| Component: | Core | Assignee: | Manoj N Palat <manoj.palat> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jarthana, manoj.palat |
| Version: | 4.5.2 | Flags: | jarthana:
review+
|
| Target Milestone: | 4.6 RC1 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: |
https://git.eclipse.org/r/72156 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=2fb52d07af8018b7544e8f642edb22d156e437f7 |
||
| Whiteboard: | |||
| Attachments: | |||
Unzip the attachment and run: bin/run.sh 4.4.2-luna-SR2 bin/run.sh 4.5.2-mars This will compile and run the custom ast program that builds all compilation units for k9mail. Notice how luna can do this in 2 seconds while mars struggles and needs 100 seconds. I see you are using Javac to compile the sources. Is this intentional? Does it matter in this particular case reproduce? If I put all these things in an Eclipse project with appropriate build path and run AstMain, I guess that should exhibit the problem too? That might make my job easier to run the program with YourKit or some other profiler. (In reply to Jay Arthanareeswaran from comment #2) > I see you are using Javac to compile the sources. I use javac to compile only one java source file; the main Ast program that showcases the bug. The k9mail app is not compiled (it is precompiled by gradle, i assume that it used javac). > Is this intentional? > Does it matter in this particular case reproduce? It shouldn't matter. > > If I put all these things in an Eclipse project with appropriate build path > and run AstMain, I guess that should exhibit the problem too? It should work. I would suggest to change AstMain then so that it finds the compilation units alone. Right now I used the shell and passed the files as args. Created attachment 261493 [details]
jvisual profiler screenshot
Screenshot of a profiler (jvisual)
Created attachment 261494 [details]
Profiler snapshot (jvisual)
Here's a profiler snapshot for parser.createASTs() using the Eclipse Mars JDT. The profiler used is jvisual that comes with the standard oracle SDK.
Created attachment 261495 [details] JDT bug showcase that works as an eclipse project Project ported to eclipse. Run from eclipse and set the working directory to: ${workspace_loc:ast}/.. If you want to attach a profiler before the call to parser.createASTs() simply pass: --pause to the program. The program will wait until you press enter to continue, giving you enough time to attach the profiler to the process. The project is also under github https://github.com/potyl/jdt-bug the Sampling data points to bug 415066 as the bottleneck - fix in bug 484361 addressed the same issue - need to look further. New Gerrit change created: https://git.eclipse.org/r/72156 (In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/72156 Manoj, for the less known, can you please explain the changes in the patch and the rationale? Thanks! (In reply to Jay Arthanareeswaran from comment #9) > (In reply to Eclipse Genie from comment #8) > > New Gerrit change created: https://git.eclipse.org/r/72156 > > Manoj, for the less known, can you please explain the changes in the patch > and the rationale? Thanks! Sure Jay - all files were listed for the consumption of the parser including non-java files which resulted in the slowdown primarily because of triggering of diagnose parser. This is corrected by filtering out non-java files. In addition, the second line of change signal that we are not interested in error reporting for this parse so that we don't get into the recovery mode. Perf Figures: 4.4.2: Parsed 264 files in 2,640 ms 4.5.2: Parsed 264 files in 91,427 ms After Fix: Parsed 264 files in 3,098 ms Patch looks good Manoj. Gerrit change https://git.eclipse.org/r/72156 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=2fb52d07af8018b7544e8f642edb22d156e437f7 Verified for 4.6 RC1 using I20160515-2000 build |
Created attachment 261480 [details] Sample project showcasing a performance regression in createASTs Since Eclipse Mars 4.5.2 we see a performance regression when calling ASTParser.createASTs(). I used a k9mail as a sample app which has 264 compilation units (android application compiled with java 7). If I use the JDT released with Eclipse Luna 4.4.2 createASTs() runs in 2 seconds. With the JDT released with Eclipse Mars 4.5.2 the same code runs in 100 seconds. All that the project does is to build the AST compilation units, nothing else. The sample project that I have does something odd it provides the compiled classes for the source files to the AST parser. This is due to the nature of android projects configured through gradle where some classes are generated by the android toolchain and by laziness I opted for including the classes in to the classpath. This means that the project has both the sources and compiled code for the compilation units. While building a small sample project that demonstrates the bug I noticed that if the compiled classes (the ones that match the sources) are stored in a jar vs a folder. There's no longer a regression in performance. Can it be that loading classes from a folder is somehow way slower than loading from a jar?