Community
Participate
Working Groups
In short the problem description is that everytime customer makes a tiny change (adding space) to his java src file, it takes 10-20 seconds to compile. In the progress view, it says compiling. Now customer has 40-45 projects and total size of the workspace is 700 MB. The product is the newest RAD version (7.5.5.1 based on 3.4.2). He also mentioned that there was no problem on 7.5.2 (also Eclipse 3.4.2). I have attached Java core file that was taken during Compiling process (see Worker-145).
Created attachment 165103 [details] javacore
Do you have the APT processing enabled ?
From the core file, it looks like APT is enabled during reconciling. APT should only be enabled during build. Please ask the customer to change this setting: 1. open project properties 2. Java Compiler > Annotation Processing 3. uncheck 'Enable processing in editor' Let me know if this helps.
Disabling processing in editor doesn't help. The only way to solve the problem is to disable the annotation processing at all but it cannot be accepted cause APT is required.
A quick look at your stack trace shows that the main thread is idle and not blocked. Please provide steps / workspace to reproduce the issue.
It seems like in the core dump the working thread is this: (native thread ID:0x1CB8, native priority:0x1, native policy:UNKNOWN) Java callstack: at org/eclipse/jdt/internal/compiler/ast/Expression.computeConversion(Bytecode PC:187(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/SingleNameReference.computeConversion(Bytecode PC:165(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/MessageSend.resolveType(Bytecode PC:1064(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/LocalDeclaration.resolve(Bytecode PC:281(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/Block.resolve(Bytecode PC:80(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/IfStatement.resolve(Bytecode PC:34(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/AbstractMethodDeclaration.resolveStatements(Bytecode PC:28(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/MethodDeclaration.resolveStatements(Bytecode PC:403(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/AbstractMethodDeclaration.resolve(Bytecode PC:40(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/TypeDeclaration.resolve(Bytecode PC:1389(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/TypeDeclaration.resolve(Bytecode PC:1(Compiled Code)) at org/eclipse/jdt/internal/compiler/ast/CompilationUnitDeclaration.resolve(Bytecode PC:1(Compiled Code)) at org/eclipse/jdt/internal/compiler/Compiler.process(Bytecode PC:77(Compiled Code)) at org/eclipse/jdt/core/dom/CompilationUnitResolver.resolve(Bytecode PC:123(Compiled Code)) at org/eclipse/jdt/core/dom/CompilationUnitResolver.resolve(Bytecode PC:133) at org/eclipse/jdt/core/dom/ASTParser.createASTs(Bytecode PC:90) at org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.createASTs(Bytecode PC:55) at org/eclipse/jdt/apt/core/internal/env/ReconcileEnv.openPipeline(Bytecode PC:31) at org/eclipse/jdt/apt/core/internal/env/AbstractCompilationEnv.newReconcileEnv(Bytecode PC:31) at org/eclipse/jdt/apt/core/internal/APTDispatchRunnable.reconcile(Bytecode PC:77) at org/eclipse/jdt/apt/core/internal/APTDispatchRunnable.runAPTDuringReconcile(Bytecode PC:16) at org/eclipse/jdt/apt/core/internal/AptCompilationParticipant.reconcile(Bytecode PC:74) at org/eclipse/jdt/internal/core/ReconcileWorkingCopyOperation$1.run(Bytecode PC:8) at org/eclipse/core/runtime/SafeRunner.run(Bytecode PC:7(Compiled Code)) at org/eclipse/jdt/internal/core/ReconcileWorkingCopyOperation.notifyParticipants(Bytecode PC:63) at org/eclipse/jdt/internal/core/ReconcileWorkingCopyOperation.executeOperation(Bytecode PC:149) at org/eclipse/jdt/internal/core/JavaModelOperation.run(Bytecode PC:43) at org/eclipse/jdt/internal/core/JavaModelOperation.runOperation(Bytecode PC:32) at org/eclipse/jdt/internal/core/CompilationUnit.reconcile(Bytecode PC:78) at org/eclipse/jdt/internal/ui/text/java/JavaReconcilingStrategy.reconcile(Bytecode PC:77) at org/eclipse/jdt/internal/ui/text/java/JavaReconcilingStrategy.access$0(Bytecode PC:3) at org/eclipse/jdt/internal/ui/text/java/JavaReconcilingStrategy$1.run(Bytecode PC:16) at org/eclipse/core/runtime/SafeRunner.run(Bytecode PC:7(Compiled Code)) at org/eclipse/jdt/internal/ui/text/java/JavaReconcilingStrategy.reconcile(Bytecode PC:48) at org/eclipse/jdt/internal/ui/text/java/JavaReconcilingStrategy.reconcile(Bytecode PC:2) at org/eclipse/jdt/internal/ui/text/CompositeReconcilingStrategy.reconcile(Bytecode PC:22) at org/eclipse/jdt/internal/ui/text/JavaCompositeReconcilingStrategy.reconcile(Bytecode PC:17) at org/eclipse/jface/text/reconciler/MonoReconciler.process(Bytecode PC:47) at org/eclipse/jface/text/reconciler/AbstractReconciler$BackgroundThread.run(Bytecode PC:201(Compiled Code)) But that should disappear if annotation processing is disabled in the reconcile. Wojciech, you said that turning off edit-time processing didn't help. What are the symptoms when edit-time processing is turned off? Is there still a big slowdown whenever the customer makes a tiny change, or does it only happen upon saving a file and rebuilding? What processors are enabled in this project? (Can you attach the .factorypath file?) How many source files are in this project, and what proportion of them contain annotations? As Dani says, it would be very helpful if you could provide a workspace or repro case that demonstrates the problem.
Hello Walter, This problem occurs only during rebuild process after saving any even very small change (e.g. add a space in code). There is no change when processing in editor is disable. As I said, problem occurs upon saving a file. There is factory path: <factorypath> <factorypathentry kind="PLUGIN" id="com.ibm.jee.ejb.annotations. processor" enabled="true" runInBatchMode="false"/> <factorypathentry kind="PLUGIN" id="com.ibm.ws.ast.wsfp.annotations. processor" enabled="true" runInBatchMode="false"/> <factorypathentry kind="PLUGIN" id="com.ibm.etools.webtools.jpa" enabled="true" runInBatchMode="false"/> <factorypathentry kind="PLUGIN" id="com.ibm.jaxrs.annotations. processor" enabled="false" runInBatchMode="false"/> </factorypath> I do not know how many projects are in a workspace. I have only information provided in description (40-45 projects, 700MB). Unfortunately, I don't have an access to any test workspace.
Well, in the absence of any more information about this particular case I think we just have to lump it in with "running annotation processors on really big workspaces is slow". You say that perf changed from RAD 7.5.2 to 7.5.5.1, with no Eclipse change (both are 3.4.2). This suggests that the annotation processors themselves may have changed, for the worse. That would be something to take up with IBM, since those don't come from Eclipse. Longer term (post 3.6) we are exploring strategies to reduce memory use during annotation processing. That might or might not make a difference here; there's not really any way to tell.
Reducing importance to "normal", since it seems this is related to non-Eclipse annotation processors (see Comment 8) and does not appear to be an issue except on an extremely large (700MB) workspace. It is quite possible that the annotation processors in question are trying to gather information about a large number of types in the typesystem, even if only a small edit has been made; if so, they are forcing re-parsing of those types, and that takes time. Frankly I think this is probably a "won't fix" in lieu of any useful information, but I'll wait a bit longer to resolve it.
Wojciech, Walter is right: there's not enough or contradicting information: the summary says that making a changes is very slow but in comment you write: " As I said, problem occurs upon saving a file". Is it now happening on typing or when saving? If it's on save then fixing bug 266299 would help. We could even mark it as dup.
Daniel, I apologize you for maybe not enough clear problem description. Yes, it occurs only during building process after save. If you are sure that solution for bug 266299 may help also in this case, you should mark this one as a duplicate.
>Daniel, >I apologize you for maybe not enough clear problem description. NP. Good we clarified it now. I've updated the summary. Walter, your thoughts.
Bug 266299 concerns reconcile only, so it would not do much about the slowness on save/rebuild, I think. In any event this is definitely not a duplicate of that bug - it might be related, but it's not a dup. Wojciech says the problem shows up on "the newest RAD version (7.5.5.1 based on 3.4.2). [...] there was no problem on 7.5.2 (also Eclipse 3.4.2)." It seems to me that a clearer understanding of what changed from 7.5.2 to 7.5.5.1 would help. That is not something that Eclipse can provide, since RAD is a proprietary product. Why did the problem not occur on 7.5.2, and what caused it to start happening on 7.5.5.1? Did the annotation processors change? If so, perhaps those annotation processors need to be written more efficiently. Again, we (Eclipse) have no information about those proprietary annotation processors. The core issue here is that APT needs information (i.e. ASTs) that the Eclipse compiler does not, and cannot, cache between compilations. The solutions to that are going to involve some combination of making APT lazier about fetching information; making the compiler better at supporting lazy evaluation (e.g., comparability of separately requested bindings); and possibly making APT use the Java Model where possible, which in turn might require adding information to the Java Model. None of that is going to come at all easily. Thus far, none of the people critically affected by the slowness of processing large workspaces seem to be able to contribute any developer resources to Eclipse.
Walter is right, the problem here is the work done during build hence the reconcile fix would not help here.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I was going to close this as WONTFIX, but then thought if someone is interested in proposing a fix, we can look at it. So, marked with helpwanted.
