Community
Participate
Working Groups
Build Identifier: Currently, org.eclipse.jdt.core.dom.ASTParser has two APIs: createAST() for compiling one compilation unit, and createASTs() for batch compilation of a bunch of compilation units. At the end of these createAST calls, the initializeDefaults() is called to reset the parser’s state, and no context is retained. So, for next createAST call, things like binding resolution are done again. The ASTParser documentation advises to use createASTs() where there are multiple compilation units for optimal performance (as createASTs() will retain the binding resolution cache till the end of compilation of all compilation units). As response to https://bugs.eclipse.org/bugs/show_bug.cgi?id=257528, two APIs were added to WorkingCopyOwner (findSource() and isPackage()). One of the fundamental needs behind the bug-257528 was to avoid traversing huge models and generating full Java source that is equivalent of the full model. The new functions in WorkingCopyOwner allowed the Java source to be generated incrementally, instead of forcing to generate all compilation units at the beginning and compile them (while knowing that only few of them are actually needed to be generated and compiled). I am wondering if it is possible to provide an API in ASTParser (or some other more suitable way), which allows user to indicate the desire to at least retain the binding resolution cache, and purge it by calling, say a new function ASTParser.reInit(). JDT is used for processing Action Language in Rational Software Architect, and while model translation, around 60% time currently in going in binding resolution. And we noticed that it is rebuilding already resolved bindings while incrementally generated compilation units are compiled one after another, so the main cost is the repetition of the binding resolution for already resolved type bindings. I am attaching a simplified test case that is representative of our usage scenario, and hope that the test case will help in clarifying this enhancement request description. The test case plug-in adds a menu item and button, action associated with them call JDTParserTester.run(), which is where compilation units are generated and compiled one after another. And later, some of the units are modified and recompiled. It is not exactly our usage scenario, but is very representative of the fact that compilation units that need to be compiled are discovered as part of a bigger system, except that a lot of other things happen between discovery/compilation of two compilation units. Reproducible: Always Steps to Reproduce: See the attached test case
Created attachment 158372 [details] Test Case
Created attachment 158373 [details] YourKit CPU Profile snap shot for the test case
Created attachment 158374 [details] YourKit CPU Profile snap shot for a test case in actual usage
Created attachment 158441 [details] YourKit CPU Profile snap shot for the test case
Created attachment 158442 [details] YourKit CPU Profile snap shot for a test case in actual usage
In my usage scenario, I create a AST (using org.eclipse.jdt.core.dom.AST.newXXX() functions) by traversing my data models (of course, this AST has no binding resolution). Then I have to un-parse it (ASTNode.toString()) to create a string that needs to be returned by WorkingCopyOwner.findSource(). And then JDT parses that String, construct the AST with binding resolution. I am wondering, probably other usage scenarios where incremental binding resolution is required, the needs could be similar. That the structural info (Class, method) would be available in some application specific internal data structure from which source code String would be constructed. It is much more easier efficient to create an AST out of that info, but the consequence is unnecessary un-parsing and parsing. Is it possible to have APIs based on ASTNode instead string, for example: ASTParser.setSource(ASTNode), and JDT does the binding resolution of the given Compilation Unit AST Node? Essentially a way to avoid unneeded un-parsing and parsing.
