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.
This issue was reported manually by thurka. It already has 75 duplicates Build: NetBeans IDE 8.0.2 (Build 201411181905) VM: Java HotSpot(TM) 64-Bit Server VM, 25.45-b02, Java(TM) SE Runtime Environment, 1.8.0_45-b15 OS: Windows 8 User Comments: GUEST: s GUEST: i want to transferring maven repository index: central GUEST: LowPerformance took 142584 ms. GUEST: ao execultar um sistema ocorre lentidao, isso em sistama desenvolvido em desktop e web. GUEST: Nothing GUEST: taking much time to operate david_mitchell: Saving a snapshot. It got to 55% then stopped GUEST: <Please provide a description of the problem or the steps to reproduce GUEST: whenever i skip between programs it takes a lot of time to show any reaction. very disappointed GUEST: so slow to open the project in java GUEST: very slow GUEST: very slow n unresponsive GUEST: After Startup I tired to open a project GUEST: <Forne
Created attachment 158528 [details] nps snapshot
This collection of slowness reports shows a problem soon after IDE startup when the current editor editor tab is changed and the underlying editor needs to be shown. The IDE is pretty much choked at this moment on IO operations (the snapshots show lots of parsing/indexing - in several threads, document initialization, classloading). This is a well known problem of overload after IDE startup. The IDE is quite slow in this situation, often unusable for long period of time. During this period, any EDT blocking "slowness" is taking significantly longer. In the case of this bug it is the need to initialize the java editor. The fact that it blocks EDT is not that important here -- the user must simply wait till the IDE becomes usable. The FormEditorSupport$JavaEditorTopComponent.getToolbarRepresentation() method captured in the reports is not the culprit, just being called by window system to show and so it calls CloneableEditor.getEditorPane() which must be called at some point anyway (and in EDT). There is nothing GUI builder related here, I believe there are other reports with different routes to the first call of CloneableEditor.getEditorPane(). Reassigning to performance as a more general problem.
Based on above evaluation - reassigning to platform/text.
I think this is a variant of bug 186117 (http://statistics.netbeans.org/analytics/detail.do?id=166520).
Thanks to Tomas Hurka who suggested how to find a solution for GUI builder (check why this is not a directly visible problem for plain Java files). Not sure how much it will help in real performance/responsiveness after startup but it seems actually possible to get rid of this particular blocking call (i.e. getEditorPane() called in EDT waiting on document to load on background). There is a trick in MultiViewEditorElement/MultiViewCloneableEditor which returns an empty toolbar representation which is filled later -- once the document is loaded. So I've rewritten FormEditorSupport to use MultiViewEditorElement for its Java editor (instead of using custom TopComponent). Besides fixing the problem it simplifies the code as well, though it creates a bit dangerous situation where the FormDataObject lookup is needed to be set to FormEditorSupport, while the lookup also needs to contain FormEditorSupport instance. (It should be fine as long as the FormEditorSupport instance creation is not triggered from the FormDataObject's lookup initialization.) http://hg.netbeans.org/jet-main/rev/0c2193ec954e