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.
On a big project backed by a ClearCase Dynamic View with many other users of the same server, earlier NetBeans versions provided immediate echoing of input characters. In 6.8 several seconds of delay often occur, which is unworkable. This has been verified on another PC on the same network. Also, a lot of exceptions happen in this version, about out-of-bounds array accesses. As a workaround I reinstalled 6.5.1 and 6.7.1, and the problem disappeared. 6.5.1 is needed as a workaround for another bug in 6.7.1, fixed in 6.8, that excludes header files from "Add Existing Items from Folders...", so I create the project in 6.5.1 and then hand it over to 6.7.1. Since this is a regression, you may know better what has changed, but it seems that an effort should be made to separate any code-completing logic and the like from basic editing, in a separate thread. Try also to simulate network and server congestion when testing NetBeans. (As an aside, I would also like to make a suggestion to allow file cacheing to a configurable location, maybe separate from other NetBeans data files, with a read-through or write-through when editing, for improved searching and scanning performance and less burden to the network and server. Additionally, a search index could be built to avoid most file accesses and provide near-instantaneous results.)
Thank you very match for performance issue investigation. Could you also attach log with exceptions?
Not ArrayIndexOutofBoundsException but: java.lang.NegativeArraySizeException at org.netbeans.modules.cnd.modelimpl.csm.UsingDeclarationImpl.getReferencedDeclaration(UsingDeclarationImpl.java:189) at org.netbeans.modules.cnd.modelimpl.csm.UsingDeclarationImpl.getReferencedDeclaration(UsingDeclarationImpl.java:101) at org.netbeans.modules.cnd.api.model.services.CsmUsingResolver.extractDeclarations(CsmUsingResolver.java:169) at org.netbeans.modules.cnd.modelimpl.impl.services.UsingResolverImpl.findUsedDeclarations(UsingResolverImpl.java:106) at org.netbeans.modules.cnd.completion.csm.CsmProjectContentResolver.getNamespaceClassesEnums(CsmProjectContentResolver.java:914) at org.netbeans.modules.cnd.completion.csm.CompletionResolverImpl.getClassesEnums(CompletionResolverImpl.java:893) at org.netbeans.modules.cnd.completion.csm.CompletionResolverImpl.resolveContext(CompletionResolverImpl.java:472) at org.netbeans.modules.cnd.completion.csm.CompletionResolverImpl.resolveContext(CompletionResolverImpl.java:246) at org.netbeans.modules.cnd.completion.csm.CompletionResolverImpl.resolve(CompletionResolverImpl.java:197) at org.netbeans.modules.cnd.completion.cplusplus.ext.CsmCompletionQuery$Context.resolve(CsmCompletionQuery.java:774) at org.netbeans.modules.cnd.completion.cplusplus.ext.CsmCompletionQuery$Context.resolveItem(CsmCompletionQuery.java:1200) at org.netbeans.modules.cnd.completion.cplusplus.ext.CsmCompletionQuery$Context.resolveExp(CsmCompletionQuery.java:1125) at org.netbeans.modules.cnd.completion.cplusplus.ext.CsmCompletionQuery.getResult(CsmCompletionQuery.java:317) at org.netbeans.modules.cnd.completion.cplusplus.ext.CsmCompletionQuery.query(CsmCompletionQuery.java:298) at org.netbeans.modules.cnd.completion.csm.CompletionUtilities.findItemsReferencedAtCaretPos(CompletionUtilities.java:150) at org.netbeans.modules.cnd.completion.impl.xref.ReferencesSupport.findDeclaration(ReferencesSupport.java:373) at org.netbeans.modules.cnd.completion.impl.xref.ReferencesSupport.findDeclaration(ReferencesSupport.java:329) at org.netbeans.modules.cnd.completion.impl.xref.ReferencesSupport.findReferencedObject(ReferencesSupport.java:222) at org.netbeans.modules.cnd.completion.impl.xref.ReferenceImpl.getReferencedObject(ReferenceImpl.java:76) at org.netbeans.modules.cnd.highlight.semantic.ModelUtils$FieldReferenceCollector.visit(ModelUtils.java:131) at org.netbeans.modules.cnd.highlight.semantic.SemanticHighlighter$2.visit(SemanticHighlighter.java:235) at org.netbeans.modules.cnd.completion.impl.xref.FileReferencesImpl._accept(FileReferencesImpl.java:141) at org.netbeans.modules.cnd.completion.impl.xref.FileReferencesImpl.accept(FileReferencesImpl.java:98) at org.netbeans.modules.cnd.highlight.semantic.SemanticHighlighter.update(SemanticHighlighter.java:228) at org.netbeans.modules.cnd.highlight.semantic.SemanticHighlighter.update(SemanticHighlighter.java:157) at org.netbeans.modules.cnd.highlight.semantic.SemanticHighlighter.run(SemanticHighlighter.java:289) at org.netbeans.modules.cnd.model.tasks.CsmFileTaskFactory$5.run(CsmFileTaskFactory.java:452) at org.netbeans.modules.cnd.model.tasks.CsmFileTaskFactory$CsmSafeRunnable.run(CsmFileTaskFactory.java:468) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:602) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1084)
printing a lot of exceptions could be the reason of slowing down, because logging is sharable between all threads (completion is done in separate thread of course). I have fixed exception part. Could you check trunk version? If it works => we can put fix in patch 6.8.1. Btw, try Tools->Options->C++->Highlighting and uncheck "Reparse of file change". Does it help? Thanks, Vladimir
Can you, please, attach full message.log file? Also it would be very helpful to see thread dump during slowness Thanks, Vladimir
Integrated into 'main-golden', will be available in build *201001051209* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/d6ba7dd7332b User: Vladimir Voskresensky <vv159170@netbeans.org> Log: fixing #179037: C++ editing very slow in 6.8 compared to previous versions - fixed exception
I've been trying to distinguish a pattern, but it's not entirely clear. There were always exceptions about problems reading from the file system (not everything is available remotely), but these do not cause performance problems with 6.7.1 (although it would seem better to catch them earlier). Unchecking "Reparse of file change" in 6.8 does not seem to make a noticeable difference. Unfortunately I can't provide log information that might contain specifics or try anything more adventurous than a final release. I'm sticking with 6.7.1 for now.
Created attachment 94266 [details] Exceptions on the current up-to-date 6.8 The exceptions are still occurring on the current up-to-date 6.8 version (includes Patch1 of 2010-02-05 as far as I can tell), in one form or another, although I haven't had the same impression of slowness yet/anymore when I tried 6.8 again instead of reverting to the previous versions, so I think I'll stick with 6.8 now. It's not clear that these things were even related (slowness, number of these exceptions), but it seems useful in itself to not let the exceptions occur (and escape). Particular to my situation: big project, lots of #include's unaccounted for (limited to using NetBeans only as a smart editor, not doable to set everything up correctly), lots of variables therefore not finding a declaration, using it on both Linux and Windows.
(In reply to comment #7) > Created an attachment (id=94266) [details] > Exceptions on the current up-to-date 6.8 Thanks. As I see exceptions are the same. > > The exceptions are still occurring on the current up-to-date 6.8 version > (includes Patch1 of 2010-02-05 as far as I can tell), in one form or another, When I have asked to check my fix => I got no reply => fix was not nominated for Patch 1 => fix was not propagated into 6.8 :-( > although I haven't had the same impression of slowness yet/anymore when I tried > 6.8 again instead of reverting to the previous versions, so I think I'll stick > with 6.8 now. It's not clear that these things were even related (slowness, > number of these exceptions), They are very related :-) And want to ask you again: please, check http://bits.netbeans.org/dev/nightly/ version (but please, backup your project files from nbproject folder) => if it is fixed for you => I will close bug and nominate for Patch 2 > but it seems useful in itself to not let the exceptions occur (and escape). That's why we are fixing bugs when they are reported :-) > Particular to my situation: big project, lots of > #include's unaccounted for (limited to using NetBeans only as a smart editor, > not doable to set everything up correctly), lots of variables therefore not > finding a declaration, using it on both Linux and Windows. This is different topic, but have you tried compiling your application with -g3 -gdwarf-2. Then in Project context menu -> Configure Code assistance action can fix a lot of your issues itself
On Linux, "grep NegativeArraySizeException ~/.netbeans/dev/var/log/messages*" is empty for nightly build 201002190200, with 178798 bytes logged so far. Possible other influences on my side: Java 1.5->1.6 (not installed yet on Windows, so only trying Linux at this time), heap size increased. No problems observed so far.
thanks for verifying