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.
This issue was reported manually by obrejla. It already has 1 duplicates Build: NetBeans IDE Dev (Build 201311080001) VM: Java HotSpot(TM) 64-Bit Server VM, 23.25-b01, Java(TM) SE Runtime Environment, 1.7.0_25-b17 OS: Windows 8 User Comments: GUEST: was it a problem? no, i don't min waiting another gazilion years for code completion to show. which it didn't Maximum slowness yet reported was 4054 ms, average is 4054
Created attachment 142599 [details] nps snapshot
Imho slow JsStructureScanner. Please, evaluate. Thanks!
Created attachment 143055 [details] nps snapshot Just writing PHP code. Profiler data shows org.netbeans.modules.javascrip2.editor is involved altrough no js files are opened in the IDE.
Created attachment 143182 [details] nps snapshot Writing php, and getting all kinds of exceptions,
Created attachment 143342 [details] SPI IndexResult Cross-Object URI Caching Support The specifics of the design of JS indexer require JSIndexSearcher.java/getTypes() and probably getSymbols() methods to use IndexResult class for each indexed element. Collection<? extends IndexResult> indexResults = index.query(JsIndex.FIELD_BASE_NAME, textForQuery, searchType, JsIndex.TERMS_BASIC_INFO); for (IndexResult indexResult : indexResults) { IndexedElement element = IndexedElement.create(indexResult); Here we iterate on all indices having separate IndexResult object each. While i've tested on my slowness case i've found all of them pointed to same file(Which means same URI as well) which is just fine(Several indexes per each module) and file was large -> mootools-1.2.6-core-nc.js(original file from mootools framework site). There was about 50 index elements in the array all pointing to this file which results in 50 costly calls to indexResult.getFile() by IndexedElement.create for same file. IndexResult class has internal cache for file/URI objects but there is no such cache for multiple separate IndexResult objects. I could alter the IndexedElement class but i decided to go deeper and update IndexResult which can enhance performance of other modules as well(Not just JS). I've added static thread-safe cache to the indexer for URI's with 10 places working like a small FIFO pool which provides the necessary caching without wasting lots of memory resources and very efficient for threads creating pool of IndexResult objects and accesses then shortly after in a loop. Sample patch is attached.
There was added caches to the JsIndexer. JsStructureScanner was also fixed. The latest reports are from Css support. Reassing to the Css.
I checked all reports from 2015 and the only one was with CSS, it is caused by slow getFileObject and it's slow because of windows native operations.Sending to PHP, since most of them are from PHP. I informed Roman about Angular - loading URLs during Code Completion. 788675 150807awt - only repaintparsing php787646 150729css code completionslow CssIndex.resolveImport()slow getFileObject - slow windows787603 150728slow phpslow getFileObject787238 150704slow angular - loading Url785971 150709javascript2 knockout783004 150601web.el782504 150616php parse 777247 150504php compute errors768381 150305php code complete
Better formatting 788675 awt - only repaint, parsing php 787646 - css code completion, slow CssIndex.resolveImport(), slow getFileObject - slow windows 787603 - slow php, slow getFileObject 787238 - slow angular - loading Url 785971 - javascript2 knockout 783004 - web.el 782504 - php parse 777247 - php compute errors 768381 - php code complete
*** Bug 238692 has been marked as a duplicate of this bug. ***
snapshot-768381 - slow FS: java.io.WinNTFileSystem.getBooleanAttributes[native] () 423 ms (26,6%) 423 ms (26,6%) snapshot-807189 - deep PHP class hierarchy, fix of issue #245279 could help snapshot-809502 - slow FS: java.io.WinNTFileSystem.canonicalize0[native] () 1 514 ms (47,7%) 1 514 ms (51,4%) snapshot-819014 - slow FS: java.io.WinNTFileSystem.canonicalize () 1 369 ms (99,3%) 1 369 ms (99,3%) snapshot-821880 - slow FS: java.io.WinNTFileSystem.canonicalize () 294 ms (17,1%) 294 ms (18%) snapshot-821928 - slow FS: java.io.WinNTFileSystem.canonicalize () 4 700 ms (62,1%) 4 700 ms (62,1%) snapshot-821970 - likely slower FS and maybe also Lookup: java.io.UnixFileSystem.getBooleanAttributes0[native] () 234 ms (6,1%) 234 ms (6,1%) org.openide.util.lookup.ProxyLookup$LazyCollection.computeDelegate () 922 ms (23,8%) 922 ms (23,8%) Based on this investigation, closing this issue as WONTFIX. Thanks for reporting.