Community
Participate
Working Groups
Created attachment 276554 [details] Snapshot Neon Migrating from Juno (4.2.2) to Neon (4.6.3), a delay saving Java files is experienced. Sampling was made using VisualVM where it was noted a different behavior in the Save procedure. Here the highlights observed at this moment: -The behavior deviation observed starts in org.eclipse.ltk.core.refactoring.TextChange.perform() where, for Neon, most time was consumed in org.eclipse.jdt.core.refactoring.CompilationUnitChange.releaseDocument() method, while in Juno, most time was consumed in org.eclipse.ltk.core.refactoring.TextFileChange.performEdits() -Deeper in the call stack, Neon accounts too many calls to Parser.parse(), while Juno remains without a call. -Neon compiles the file as part of the save process, while in Juno the namespace "org.eclipse.jdt.internal.compiler.*" is not even present in the call tree. -java.io is performed in the leafs of the call three. Delay observed is more than 10 seconds. Please Advise Snapshots Attached
David, 4.6 is not supported anymore. Please grab 4.9 and check if you still have this regression.
Created attachment 276555 [details] Snapshot Juno
Went through the snapshots and just looking at the history of TextFileChange and such, I didn't find any clue. Just have few questions: 1. Can we confirm that the experiments between two versions were on the same workspace and the action performed was same on the same file. 2. Confirm that no compiler or editor preference was changed explicitly? 3. What exactly was the change done? 4. Can you confirm that this does/doesn't happen when a non-java file is changed. Noopur, please add if you have more questions.
(In reply to Jay Arthanareeswaran from comment #3) > Noopur, please add if you have more questions. I have a few additional queries: 1. Can you compare the checked/enabled save actions between the two releases under Preferences > Java > Editor > Save Actions to see if there is a change? Also, compare the additional save actions under "Configure". 2. Can you please try to narrow it down by unchecking the save actions one by one? This will help us to identify if a particular save action is causing the problem. 3. If possible, attach a file or sample project along with the steps which show the issue.
Created attachment 276801 [details] Save Actions Screen
(In reply to Jay Arthanareeswaran from comment #3) > Went through the snapshots and just looking at the history of TextFileChange > and such, I didn't find any clue. > > Just have few questions: > > 1. Can we confirm that the experiments between two versions were on the same > workspace and the action performed was same on the same file. That’s correct. > > 2. Confirm that no compiler or editor preference was changed explicitly? That’s correct. > > 3. What exactly was the change done? Varies. But makes no difference weather a single comment was added or several dozen lines of Java Method. Lag was observed in all cases. > > 4. Can you confirm that this does/doesn't happen when a non-java file is > changed. That’s correct. A change on a text-file for example is instantaneous. > > Noopur, please add if you have more questions. (In reply to Noopur Gupta from comment #4) > (In reply to Jay Arthanareeswaran from comment #3) > > Noopur, please add if you have more questions. > I have a few additional queries: > > 1. Can you compare the checked/enabled save actions between the two releases > under Preferences > Java > Editor > Save Actions to see if there is a > change? Also, compare the additional save actions under "Configure". Both in 9.1 & 9.6 this is what the Save Actions settings look like: (see attachment 276801 [details] ) > > 2. Can you please try to narrow it down by unchecking the save actions one > by one? This will help us to identify if a particular save action is causing > the problem. Unchecked “organize imports” : 24 seconds on save Unchecked “format source code”: 8 seconds on save > > 3. If possible, attach a file or sample project along with the steps which > show the issue. Sorry, It is not possible
Correction. I wrote: >'Both in 9.1 & 9.6 this is what the Save Actions settings look like' but it is: 'Both in Juno (4.2.2) & Neon (4.6.3) this is what the Save Actions settings look like'
Manoj, does the window include our formatter changes by any chance?
(In reply to Jay Arthanareeswaran from comment #8) > Manoj, does the window include our formatter changes by any chance? Yes, the formatter redesign happened in Mars (4.5). But there were some serious optimizations after 4.6, so it's definitely worth checking the latest version.
(In reply to Mateusz Matela from comment #9) > (In reply to Jay Arthanareeswaran from comment #8) > > Manoj, does the window include our formatter changes by any chance? > > Yes, the formatter redesign happened in Mars (4.5). But there were some > serious optimizations after 4.6, so it's definitely worth checking the > latest version. By any chance can you recollect what those changes were?
(In reply to Jay Arthanareeswaran from comment #10) > By any chance can you recollect what those changes were? Not right away, I'd need to look at the commits. But it would be some obscure technical details, why do you ask?
Hi, is it possible to provide the list of commits that were delivered? this is blocking a customer that is not able to migrate to the latest Eclipse version, thanks!
(In reply to Cesar Orozco from comment #12) I was mostly thinking about bug 493296. Before cherry-picking, you can easily check if given Eclipse version is really faster - no need to migrate anything, just run with an empty workspace, open the java file that causes problems and press Ctrl+Shift+F.
(In reply to Cesar Orozco from comment #12) > Hi, is it possible to provide the list of commits that were delivered? this > is blocking a customer that is not able to migrate to the latest Eclipse > version, thanks! latest version of Eclipse is 4.10 [or you can try 4.9]. Did you try on any of the above?
(In reply to David Christensen from comment #6) > > > > 2. Can you please try to narrow it down by unchecking the save actions one > > by one? This will help us to identify if a particular save action is causing > > the problem. > > Unchecked “organize imports” : 24 seconds on save > Unchecked “format source code”: 8 seconds on save > > > > > 3. If possible, attach a file or sample project along with the steps which > > show the issue. > > Sorry, It is not possible Since organize imports is also found to be a culprit, Is it possible to copy just the part which contains the imports including comments if any so that to "fabricate" a test case/project that could reproduce the issue? You can obfuscate the client-specific import names, but leave the standard imports in-tact. Let us know whether that is possible.
Please get confirmation from the customer whether disabling 'Format source code' on Save fixes the problem for them.
Yes, when the "Format source code" option is disabled the performance is improved
(In reply to Cesar Orozco from comment #17) > Yes, when the "Format source code" option is disabled the performance is > improved This does not answer my question: " Please get confirmation from the customer whether disabling 'Format source code' on Save fixes the problem for them. " So, please answer with only YES or NO.
(In reply to Dani Megert from comment #16) > Please get confirmation from the customer whether disabling 'Format source > code' on Save fixes the problem for them. "Yes. Disabling formatting source code and organize imports improves the time to save a file. However, we cannot leave that option turned off as it is quite useful for us during development." -Customer
(In reply to Manoj Palat from comment #15) > Since organize imports is also found to be a culprit, Is it possible to copy > just the part which contains the imports including comments if any so that > to "fabricate" a test case/project that could reproduce the issue? > You can obfuscate the client-specific import names, but leave the standard > imports in-tact. Let us know whether that is possible. Here is the requested data to troubleshoot the formatter perf: It is an example of imports from one of their source files. They've managed to obfuscate the organizational specific imports. Also provided a test class to use the imports against. Both files are attached.
Created attachment 277003 [details] example of imports
Created attachment 277004 [details] MainTestCase.java
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.
