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.
I'm not sure whether this idea is feasible or not (you'd have to measure it) but I noticed that currently Netbeans scans the classpath using a single core (probably using a single thread). If you were to break this down into multiple threads then multi-core systems would run the computational end a lot faster. It remains to be seen whether the overall process is CPU or I/O-bound. The same technique should probably be checked for the refactoring module ("initializing" takes a long time).
Reassigning to java.
It's feasible, it needs to be prototyped. During the initial scan the most load is on the IO, it needs to be measured if adding another core into the game will improve the scanning or it will cause IO contention and will slow down the scan process.
This is still valid request. Project scanning still only happens in a single thread. I/O is not a bottleneck here - I have most files cached and there are barely few reads coming from NetBeans. Could this be considered for 7.next please?
Another task which takes an inordinate amount of time is code-formatting. This is even more apparent when running on weaker devices like laptops. Code formatting uses 15% of the CPU (1 out of 8 cores running at 100%) and takes 3-5 seconds on average even for relatively small files. I think we should convert this into an umbrella issue and evaluate which tasks are best suited for parallelization.