This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Build: NetBeans IDE Dev (Build 200909210201) VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.28-15-generic, i386 User comments: Maximum slowness yet reported was 13292 ms, average is 12380
Copying evaluation from a "duplicate" issue 170495 - tpavek wrote: The profiling snapshots show saving forms take long due to resolving imports to eliminate fully qualified names in the generated code (code is generated as part of saving). Saving is intentionaly replanned to AWT event thread. Lots of operations in GUI builder needs to be done in AWT thread; I don't remember the exact reasons why it is needed also for saving [1] - but changing that is very likely non-trivial. A workaround is to set the form to use fully qualified names (not try to eliminate them), then saving is fast. [1] http://hg.netbeans.org/main/rev/4aae6d952a0a
*** Issue 175530 has been marked as a duplicate of this issue. ***
IMHO this is an P1, since we have more than 50 duplicates at http://statistics.netbeans.org/analytics/detail.do?id=155052 with the same behaviour. Well, about don't say to me just don't use the feature where Matisse should use imports instead FQN, I will not just don't use an feature because an regression. For versions before 6.7 I have no problems saving forms. Another point is that just use wait cursor is not acceptable, the fix-import should be fast as before to increase the users experience. We have several users here and all of us face this kind of problem, even for 6.7.
The FQN elimination feature itself is the "regression", the reason why it is slow. Saving used to be fast when there was no FQN elimination available. Honestly, we don't know how to make it faster. Even replaning out of AWT is difficult for us and probably not helping at all, because save action must be synchronous. So if the FQN elimination is found unbearably slow, I'm afraid the only option for 6.8 is to turn it off... Other ideas?
> The FQN elimination feature itself is the "regression", the reason why it is slow. Saving used to be fast when there > was no FQN elimination available. No, even an already saved form, if I just edit an text field property, text property for example, and save again, it is really slow again. I just can't see any difference between save an new form and an already saved form, and the time increase with the size of form as expected. > Honestly, we don't know how to make it faster. Even replaning out of AWT is difficult for us and probably not helping > at all, because save action must be synchronous. So if the FQN elimination is found unbearably slow, I'm afraid the > only option for 6.8 is to turn it off... Other ideas? No, I have no ideas about it... not yet at least :( Just to make clear, I just testing these things in 6.5.1 and it is slow as 6.8. I really thought it was faster. BTW, I fell fix-import in editor really slower than before, what is the probably root cause in this issue. I can see in 6.8 the slowness detector for almost all fix-imports I do all day long, and I just can't see my IDE freeze in previous versions (previous than 6.7).
*** Bug 187938 has been marked as a duplicate of this bug. ***
*** Bug 188733 has been marked as a duplicate of this bug. ***