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.

Bug 159566

Summary:	IDE becomes very slow after cutting a class
Product:	editor	Reporter:	Jesse Glick <jglick>
Component:	Refactoring	Assignee:	Jan Pokorsky <jpokorsky>
Status:	RESOLVED DUPLICATE
Severity:	blocker	CC:	issues, nleck
Priority:	P3	Keywords:	PERFORMANCE
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Attachments:	Some thread dumps stack traces

Description Jesse Glick 2009-03-03 21:03:33 UTC

If I move a class using cut & paste, moving around in the Projects tab using the arrow keys becomes painfully slow, with
EQ frozen at 100% CPU for several seconds just to move a few nodes up or down.
refactoring.impl.ClipboardConvertor$RefactoringPaste seems to be responsible, e.g.

....
	at org.netbeans.spi.project.support.ant.SourcesHelper$SourcesImpl.getSourceGroups(SourcesHelper.java:745)
	at org.netbeans.spi.project.support.LookupProviderSupport$SourcesImpl.getSourceGroups(LookupProviderSupport.java:279)
	at org.netbeans.modules.refactoring.java.RetoucheUtils.isOnSourceClasspath(RetoucheUtils.java:341)
	at org.netbeans.modules.refactoring.java.ui.RefactoringActionsProvider.canMove(RefactoringActionsProvider.java:534)
	at org.netbeans.modules.refactoring.api.impl.ActionsImplementationFactory.canMove(ActionsImplementationFactory.java:121)
	at org.netbeans.modules.refactoring.spi.impl.MoveAction.enable(MoveAction.java:74)
	at
org.netbeans.modules.refactoring.spi.impl.RefactoringGlobalAction$ContextAction.isEnabled(RefactoringGlobalAction.java:166)
	at
org.netbeans.modules.refactoring.impl.ClipboardConvertor$RefactoringPaste$RefactoringPasteType.canHandle(ClipboardConvertor.java:135)
	at org.netbeans.modules.refactoring.impl.ClipboardConvertor$RefactoringPaste.types(ClipboardConvertor.java:121)
	at org.openide.nodes.AbstractNode.createPasteTypes(AbstractNode.java:528)
	at org.openide.nodes.AbstractNode.getPasteTypes(AbstractNode.java:540)
	at org.openide.nodes.FilterNode.getPasteTypes(FilterNode.java:687)
	at org.openide.explorer.ExplorerActionsImpl.updatePasteTypes(ExplorerActionsImpl.java:344)
....

Comment 1 Jesse Glick 2009-03-03 21:05:54 UTC

Created attachment 77676 [details]
Some thread dumps

Comment 2 Jan Pokorsky 2009-03-05 19:24:54 UTC

Product Version: NetBeans IDE Dev (Build 090305)
Java: 1.6.0_10; Java HotSpot(TM) Client VM 11.0-b15
System: Linux version 2.6.27-11-generic running on i386; UTF-8; en_US (nb)

I cannot reproduce any slowdown even in session with 8 j2se + 2 freeform open projects or in session with ~60 netbeans +
2 j2se open projects.

RetoucheUtils.isOnSourceClasspath contains a strange workaround that I will investigate. It calls
ProjectUtils.getSources(pr).getSourceGroups for each open project.

But what is even stranger is why ClipboardConvertor.convert is called so excessively. It is 2-10 calls per up or down
key stroke. I will attach stack traces showing the traffic generated by clipboard support after pressing ctrl+x on one
java node in the projects view.

Comment 3 Jan Pokorsky 2009-03-05 19:29:47 UTC

Created attachment 77780 [details]
stack traces

Comment 4 Jesse Glick 2009-03-05 19:34:35 UTC

Not P2 if you cannot trivially reproduce.

Comment 5 Jan Pokorsky 2009-04-27 13:08:01 UTC

*** Issue 163694 has been marked as a duplicate of this issue. ***

Comment 6 Jan Pokorsky 2009-06-05 10:54:14 UTC

*** Issue 166573 has been marked as a duplicate of this issue. ***

Comment 7 Jaroslav Tulach 2009-06-06 07:59:52 UTC

Duplicate was P2.

Comment 8 Jaroslav Tulach 2009-06-09 14:52:43 UTC

Btw. profiler snapshot is available: http://www.netbeans.org/nonav/issues/showattachment.cgi/83218/refactoring-31s.nps

Comment 9 Tomas Pavek 2009-09-10 12:41:42 UTC

Issue 167256 seems to fix the problem on the explorer side (eliminating the number of calls to update the paste action).
should help with this significantly). Please reopen this issue if it does not seem to be good enough, then perhaps the
check on refactoring side would have to be made faster.

*** This issue has been marked as a duplicate of 167256 ***