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.
Now the project is opened from persistent system and global data is not available in memory cache => first use of code completion could be very slow. The same situation appears when code assistance is not used for a long time (data is offload from memory)
As it was discussed many times we need to give priority parsing to the file that is currently active in the editor. Besides it is generally good and logical thing, it would help to resolve this particular issue.
The same situation occurs when user calls code completion while opening a project for the first time (the project is not in the repository yet) performance tests show that the appearing time can exceed 10 seconds.
*** Issue 101624 has been marked as a duplicate of this issue. ***
I believe the slowness of code completion during initial project parsing is quite a different issue (from both end user and implementation point of view). As to slowness of code completion during initial project parsing, I would propose to revisit the thresholds. Yes, during initial parsing there might be, say, 10 seconds delay in completion. But let's look at known Java IDEs: Netbeans, Eclipse, Idea. Neither of these allow using completion until the project is completely parsed (which make take from dozens of seconds to several minutes!). So I don't think this as a serious issue. Anyhow, this IZ concerns only the slowness related with persistence - when user don't use code assistance for a long period of time and when user opens a project that is loaded from persistence.
Performance tests show that after initial project loading code model features works ok. The issue concerns mostly the situation when you work with a large project then switch to other tasks (or have a lunch); then, upon your return, you discover that the 1-st launch of code completion is very slow. The second one is as usual, though. I'd say it's quite normal price of not consuming too much resident memory. Look at nearly any other large memory-consuming application. After a certain period of inactivity it becomes swapped and comes up from swap for a noticeable time. Then it works ok. I'm not saying we shouldn't improve this. But it's rather an enhancement than a defect.
close developer's issue because exists user issue *** This bug has been marked as a duplicate of bug 184370 ***