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 nbms-and-javadoc-4704-on-100118) VM: Java HotSpot(TM) Server VM, 16.0-b13, Java(TM) SE Runtime Environment, 1.6.0_18-b07 OS: Windows XP User Comments: GUEST: invoked cc in test Maximum slowness yet reported was 9875 ms, average is 5572
Created attachment 93441 [details] nps snapshot
The first few reports indicate the CC is blocked by not all projects being open: http://statistics.netbeans.org/exceptions/exception.do?id=328527 The other shows that the CC waits for org.netbeans.modules.java.source.tasklist.TaskCache.refreshTransaction() and org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsListeners.add() http://statistics.netbeans.org/exceptions/exception.do?id=328565
Integrated into 'main-golden', will be available in build *201002040200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/0661f74f1891 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #179727: Don't start the code completion self profiling when 'scanning in progress...'. It is known that currently no (java) completion is shown while the scanning is running and it is useless to gather more information about such case. As it is hard to find out from editor.completion module that parsing.api is scanning, the actual method relies on 'polite wait message' being provided by the completion provider.
I have observed that with large files (even for a 1000 line file) this is very evident. Also, (not sure if this is related but) along with code complete, the inspect Members function is equally slow.
In the NB 6.9 M1 there was a regression in the persistent caches used by code completion to show param names im methods of class files (rt.jar, libs) which may cause significant slowdown. The caching was recently fixed: http://hg.netbeans.org/jet-main/rev/f1c0e7896b92
Do you know if this fixed has made it to the nightly build -> 201002260200?
Do you know if this fix has made it to the nightly build -> 201002260200?
No, the fix was integrated today into jet-main repository. It will take some time to propagate into the night build.
Thanks. Will test this out once it is available in the nightly.
Anyone tested it again? The patch was already integrated [1] and should be available after Feb 26. [1] http://hg.netbeans.org/main/rev/f1c0e7896b92
I have tested this. Code completion is a lot better now but inspect members function still seems to be slow. Its hard for me to quantify how slow.
I´ve tested it at build 201003040200. I´ve still some slowness-Detections. Please have a look at report http://statistics.netbeans.org/analytics/exception.do?id=348021.
I just tested this w/ 201003050200 and there is still a significant slowdown on the groovy code. I have a Grails project : in Groovy code, when I hit "." for code completion, it takes 2-3 seconds for the initial popup to show up. Then, if I type the first couple of characters in the method , it takes additional 2-3 seconds to display the matching subset. I'll file a separate issue on the Grails side. In java code, code completion in the same project is instantaneous. Overall, it is very unusable.
The issue has 504 duplicates and affects NB JavaFX plugin
This issue is just a placeholder (pool) for the automatically collected performance problems related to code completion, as a base for further analysis. For specific problems separate issues should be filed. If you can see snapshots related to JavaFX code completion, please file a separate issue for that and link the snapshots (or better separate them from this report to their own).
There are some infrastructure problems that should be fixed: (1) The sampling may not stop sometimes - issue 183201. (2) Since about 100226, the snapshot have absurdly high spend time shown in the table (like millions ms). The snapshots themselves are good. (3) There seems to be no minimum time the sampling should run to produce reasonable snapshot. It starts with a delay, but if CC appears short after that the snapshot may be too short. Such snapshots should not be probably reported. E.g. saw a snapshot of 56ms which is way too little to say anything useful. I guess the minimum time should be something like 300ms at least.
The mentioned 3 problems have been addressed by fix of issue 183832. Now the self-profiling starts after 750ms, a problem is reported and snapshot created if it exceeds 2s (i.e. should have at least 1250ms long snapshots).
We will analyze the snapshots and conclude what shall be fixed for post 6.9 version.
It is slow more often than not. Very very slow. Makes Groovy so unbearable when using code completion?
Not sure where you guys are on this, but the current version below is pretty slow. Over the last month I've been back to writing c++ and the "code completion is slow" popup occurs about 1 in 4 times I hit a dot or a pointer. And the 3 out of 4 times it does not popup it is never instantaneous. Usually over one second. I'll bump this to P2. I spend about half my time writing code with VS 2010 on a VIAO laptop with a ultra low power 1.6Ghz processor, and code completion there is always instantaneous. Netbeans, on the other hand, I run on a 2.5 Ghz core 2 quad. Product Version: NetBeans IDE Dev (Build 201008280001) Java: 1.6.0_18; Java HotSpot(TM) 64-Bit Server VM 16.0-b13 System: Linux version 2.6.32.9-70.fc12.x86_64 running on amd64; UTF-8; en_US (nb) Userdir: /home/toddb/.netbeans/dev
remove me from CC List
Just downloaded Sun JDK 1.6 v22 and NetBeans 6.9.1 Groovy code completion is painfully slow, far faster to type everything out manually. Of course, just typing any text within a Groovy class rockets the CPU to 80-100%, so looks like code completion is not the sole problem. Fedora 13 x64 on Sony Vaio F series laptop: Intel quad-core extreme + 8GB RAM. I love NB, but this is a show stopper, can't waste time coding long-hand.
Have you considered netbean's cache as a source of this problem? ~ .netbeans/6.9/var/cache I added a bug recently about cache corruption because code completion completely failed a few times in 6.9.1. (#190832). Don't know how the cache is designed, but it appears to either become corrupted or just get too large. Delete that directory (netbeans can not be open). NB will rebuild and performance will improve for a while. My cache is now: 250 MB 31,000 files, 6000 folders. Delete and reopen the same project. Rebuild cache is 110 MB.
I think the cache is the problem...NetBeans must include a high perfermance cache system. The cache is not only for code completion, but also for scan, go to, find usage... 1. why scan the jar files when I opened netbeans everytime. For a java project, it need scan the jar once when I added it to the project. Other jar files, such as Java Platform(java 6 sdk, java 7 sdk),Java Libraries and Java EE server, only scan once when added it to NetBeans IDE. They can be share for all Projects, in a project, only need add a reference to the cached result. 2. the maven "go to" feature to find the maven artifact is 10 time slower than the Eclipse m2eclipse. 3. the Maven jar scan is another problem, why is scanned periodly. The central maven repository is shipped with the cached info about the whole repository. Download it and reuse it. In NetBeans 7.0, I noticed that it declared it can monitor external changes effetively. Why not only scan changed jar in local maven repository?
#1 - when a JAR has been scanned before, NB will subsequently only check its timestamp to make sure it has not since changed. That is not related to this issue. #2 probably unrelated; do not discuss here. #3 also unrelated; see discussion in bug #190675.
To be fair I just hit the short cut to autocomplete the code without typing anything in. This was in a drupal project so there is a lot of stuff to bring back.
Although the problem are not related to those I motioned...I think all of them are caused by the cache system of NetBeans(I do not know if there is a cache system in NetBeans for all), if there have no effective algorithm in cache system...currently patch and patch again, it can not resolve the problem at all.
I think the most slowness-reports are while "Scanning projects". While this task runs, many other features are very slow or still not available (Code-Completion, GoToClass, ...). Is there no way to make a dirty-read, while scanning projects? At 6.8 or 6.8 was a big point "Make the IDE useable while scanning projects". This point is much better, but the dirty-read-feature is missing?
Created attachment 103504 [details] profiler dump Had only one project open, IDE seemed quiescent. Several times today I've seen CPU usage jump up very high. Build number 201012010001. Will also attach log file.
Created attachment 103505 [details] NetBeans log file NB was running with -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE
Just for the record, according to Dusan Balek the snapshot from Glenn has nothing to do with code completion as well as 20 latest exception reports.
Yestarday somtimes code completion worked perfect, but today i must wait up to 10 sec.
I'm seeing this sort of thing on Mac OS X as well. It does seem to be happening during the 'Scanning projects' phase of having NB open a project.
I?m seeing this today while writing XML code in a DocBook file. It's really annoying as it stops every few seconds, and BTW it's completely unable to auto-complete the XML tags. I've uploaded a snapshot by means of the IDE.
Removing var/cache didn't solve the problem. It reappeared immediately after NetBeans was restarted.
It seems fairly obvious that the locking model for code completion is too coarse.
I don't know. It is weakly computer and many processes. That's all...
It seems that any long running task or quite intensive task is blocking other activities. Yesterday while the IDE was updating the maven repository index the whole IDE just ground to a halt and stopped me from working. Especially code completion.
Please evaluate : if you do not plan to fix it for NB 7.0 ask for waiver ASAP.
My 50 cents: Netbeans is currently utterly un-usable (for my projects at least) because of performance problems. These performance problems surely can not be delayed to after 7.0 release??
+1 to the previous "utterly unusable" comment.
Note to everyone: It has been suggested on the NetCAT mailing list that we should re-file this bug since the slowness may have different causes depending on the type of file being edited. In my case it's the JSF editor, but others have reported slowness with the PHP editor etc. It seems that the exception reporter automatically assigned these as duplicates of one another when they're not. Ideally, test this using the latest RC build.
I have been using the daily php builds and can tell that code completion does not work for most of the time. Further typing in the php editor is annoyingly slow. For example scrolling up and down using the arrow keys in php files containing 2000 or more lines is really slow and the editor is barely usable.
I've been using 7.0 beta 2 with Java code and it is great. The code completion works every time.
It's really erratic for me. And depends heavily on how long NetBeans has been running. It'll be great for a while when I first fire it up. But after a few hours it becomes unusable. Long (20 second-ish) pauses every 10-ish keystrokes. I'd call this a P1 show-stopper
Code completion has always been *VERY SLOW*, taking 3-5 secs each time autocompletion is called. Please fix it, it's the most annoying issue of NB so far.
dstrupl sent request for waiver to nbdev@netbeans.org . So removing 70 fix candidate and change Target Milestone to TBD.
It seems pretty clear at this point that the NBDEV team has no ability to provide performant code completion. It seems like it is time to rip out everything that uses the cache, as designed and just start over. This issue seems to be the #1 reason why people choose to NOT use netbeans. It's a major roadblock and I am completely convinced after 5 years of complaining about it and opening issue after issue both explicitly and through the automated mechanisms this issue is tracking that there is no solution that will ever happen. The NBDEV folks are stuck in their ways, convinced they know everything, refuse to listen to the users and just can not imagine how we can be having problems with their golden GEM of an IDE. There is no way to implement a cache without its access being completely seamless for both read and write. Blocking readers because writers are busy and the like has been demonstrated in java.util.concurrent related research as impossible to be performant. I really don't know how else to say this. It's hard to be this critical given all the time and energy that the NBDEV team does put into Netbeans. But the place where the project is at now, is just terrible. There is just too much stuff that wrong with the source code scanning and the symbol lookup mechanisms. It's a lot of software, and all the micro tuning being done is just not fixing much of anything it seems.
greggwon, your comments are neither constructive nor useful. While I share your frustration at the poor state of code completion in current versions of NB, it's clear that the team is aware of the situation and will fix it if they can. If they can't fix it, you are welcome to try another editor. You can always fix the problem yourself and submit a patch.
What I believe gregwon is trying to say is that there may be no solution other than rewriting whole lot. I know the pain as I am working on a massive codebase (some of which I cant access with NetBeans due to slowness of code completion with larger files) and I can understand that some things are unfixable due to initial design and approach of developers. So as much as I really like NetBeans I hope something can be done about it's occasional (for me) slowness because it really renders it useless at times. My suggestion - introduce an easily accessible button on the panel somewhere (next to memory usage graph?) 'Disable Code Completion' or anything that is slow but not 100% necessary. Then I will be able to easily switch it off for large files and continue to use other features of NetBeans without CC. My argument is - I can code without CC but I cant code with 2 sec intervals between every letter I type. Cheers!
There should be an OS option that's just "Windows," as this affects at least XP through 7.
I changed the OS option to All as this seems to affect all OS systems.
just trying to remove myself from this behemoth I just can't cope with it...
exception report 434322 => Bug 197314 - CSS completion blocked by CSS parser error analysis
All : do not change Target Milestone, Platform.
Performing a service to humanity and removing 503 people from the cc list for this bug. Anyone who actually *wants* notification every time something inconsequential changes here, feel free to re-add yourself. If anyone admining the site needs a copy of the original cc list, ask me for it.
(In reply to comment #56) > Performing a service to humanity and removing 503 people from the cc list for > this bug. Anyone who actually *wants* notification every time something > inconsequential changes here, feel free to re-add yourself. > > If anyone admining the site needs a copy of the original cc list, ask me for > it. Thanx
(In reply to comment #56) > If anyone admining the site needs a copy of the original cc list, ask me for > it. Available from: http://netbeans.org/bugzilla/show_activity.cgi?id=179727
We improved the way Slow Code Completion reports are treated and there shouldn't be a new report marked as duplicate of this issue anymore. All newly reported issues will go directly to particular areas.
SPAM - Removed by Administrator