Community
Participate
Working Groups
Using M8 on GTK. Accidentally performed Source->Format (java conventions) on a large, previously unformatted class (WorkbenchWindow). Two problems: 1. The operation, while taking a very long time, blocked the UI. 2. After it completed, I performed Edit->Undo and was surprised that the undo operation took about the same length of time (?) Perhaps performance can be improved under certain conditions if the the code formatter could consider copying the text before the format starts and implement undo as a text replace using the entire original text? (It is so slow to undo, I'm just guessing here that it is doing the inverse of the format, operation by operation)
please provide your formatter settings.
i used 'Java Conventions' with the default settings (as they appeared in m8)
*** Bug 57499 has been marked as a duplicate of this bug. ***
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
I don't find formatting to take a long time any more. Even re-formatting all of StyledText.java on my Mac laptop took less than 20 seconds. However, the UI *is* still unresponsive during this time. Does it make sense to use the busyCursorWhile(...) support here?
20 seconds seems long to me. If you have comment formatting enabled, this may slow things down. I just noticed that we copy the entire document in the comment formatter using IDocument.get().
My test case was: - open StyledText.java - use find/replace dialog to replace all tabs with nothing (i.e. remove all tabs) - use find/repace dialog to replace "if (" with "if (" - select all - "Source" -> "Format" This takes 18..20 seconds on my 1.33GHz G4 laptop.
*** This bug has been marked as a duplicate of 72319 ***
