Will "Performance" (and stability) sometime appear in NetBeans roadmap?

"NukemBy" <[email protected]> Mon, 19 Dec 2016 18:46:53 +0000
Newsgroups gmane.comp.java.netbeans.devel
Message-ID <[email protected]>
Unfortunately I'm not free enough to constantly allocate some time on improvements of NetBeans - this means I will not have time on maintaining a Wiki page, especially on a regular basis.

I've spent two+ weeks of my 'spare' time on profiling of NB after 8.2 was released - because was very disappointed about it performance.
My findings are already posted in bugzilla, mostly alone with my IMHO regarding reasons and potential fixes (sometime not correct).

If someone would like to maintain some wiki, below are some inputs from me to start.

- - - - - 

I would classify slowness (annoying me the most) into following categories.

> “Slowness of Background scan” - nevertheless it is 'background' and is supposed to not affect user experience, it actually does in two following areas
=========================================

* both BG scan and interactive editors excessively use same cache store and heavy load on cache from bg scan causes editors to be extremely laggy
* some user actions become enabled only after bg scan is complete


I feel time of bg scan can be reduced by 80-90% on Windows and 40-50% on *nix (in context of projects having Java-or-like code plus various JS scripts – in my particular context – huge multi-module WEB application). This ‘extra’ time mostly goes from:
-	Excessive queries to File System (30-40% on Windows, 5% on *nix)  …
-	… caused by rather inefficient java package cache (20-30% on all platforms)
-	Inefficient file-processing algorithms in some particular cases which may not be the case for everyone (10-20% on all platforms)

It may happen that fixing implementation of ‘java package cache’ will also fix performance of ‘File System’ because number of file queries will change scale from ‘millions’ to ‘thousands’ and consequently also significantly reduce severity of some other code issues.

Issues for this part:

>> Regarding “File System on windows”
-------------------------------------------------
Implement another way of caching of File instances in NetBeans
https://netbeans.org/bugzilla/show_bug.cgi?id=268744 

FileUtil.toFileObject() - why just not call directly FileBasedFileSystem.getFileObject() ?
https://netbeans.org/bugzilla/show_bug.cgi?id=268123 

Excessive calls to File.isDirectory() cause performance problems
https://netbeans.org/bugzilla/show_bug.cgi?id=268087 

Performance issue in RepositoryForBinaryQueryImpl.getJarMetadataCoordinatesIntern()
https://netbeans.org/bugzilla/show_bug.cgi?id=268045 

Performance issue: FileUtil.normalizedRef cache is cleaned too frequently
https://netbeans.org/bugzilla/show_bug.cgi?id=268027 

Performance issue in BaseFileObj.getPath --> FileName.getName 
https://netbeans.org/bugzilla/show_bug.cgi?id=268026

"assert assertNormalized()" in FileUtil.toFile() is the cause of general slowness of NetBeans
https://netbeans.org/bugzilla/show_bug.cgi?id=267990 

>> Regarding “java package cache”
-------------------------------------------------

Background scan of not so large project runs for 40 minutes !!!
https://netbeans.org/bugzilla/show_bug.cgi?id=269229 

Performance issue - URL LuceneIndexFactory.getIndexFolder() takes 10% of RepositoryUpdater.worker
https://netbeans.org/bugzilla/show_bug.cgi?id=268108 

'Heavy' CPU-intensive implementation of CachingArchiveProvider.toURI()
https://netbeans.org/bugzilla/show_bug.cgi?id=268292 

Slow and Weird auto-suggest for Exception class names in New Breakpoint dialog
https://netbeans.org/bugzilla/show_bug.cgi?id=250470 


>> Regarding “Inefficient file-processing algorithms”
-------------------------------------------------

Fix performance in 'javascript2' code (JavaScript scanner)
https://netbeans.org/bugzilla/show_bug.cgi?id=268745 

Replace EnumSet.of() with EnumSet.noneOf().add() in UsagesData.java (Java scanner)
https://netbeans.org/bugzilla/show_bug.cgi?id=268746 

Excessive InapplicableMethodException causes slowness in bg-scan during initial load.
https://netbeans.org/bugzilla/show_bug.cgi?id=268310 

Html Editor hangs for 3-4 minutes on 'incorrect' HTML (Netbeans completely freezes)
https://netbeans.org/bugzilla/show_bug.cgi?id=268087 



> “Slowness of Java debugger” (because of these issues I switched to IDEA currently for all Java staff)
=========================================

Slow evaluation of Watch variables during debug (Java Debugger)
https://netbeans.org/bugzilla/show_bug.cgi?id=249305

NB hangs while debugging (Java Debugger)
https://netbeans.org/bugzilla/show_bug.cgi?id=268748

"Debugging view" hardly flickers while evaluation of watch variables (Java Debugger)
https://netbeans.org/bugzilla/show_bug.cgi?id=269018 

Breakpoints cause unneeded lengthy loading of projects (Java Debugger)
https://netbeans.org/bugzilla/show_bug.cgi?id=269121 


> “Various other staff, which is noticed across the code”
=========================================

Excessive IO coming from TrieDictionary (causes 7-10 secs delay in initial project load) - occurs once on clean-cache start
https://netbeans.org/bugzilla/show_bug.cgi?id=268094

Performance issue - ancient synchronized implementations of listener subscriptions
https://netbeans.org/bugzilla/show_bug.cgi?id=268047 

Performance issue in (jpda) MainProjectManager.getMainProject() -> isDependent(lastSelectedProject, current)
https://netbeans.org/bugzilla/show_bug.cgi?id=268028 

SimpleFileOwnerQueryImplementation.getOwner() is another cause of major NetBeans slownes
https://netbeans.org/bugzilla/show_bug.cgi?id=268024