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.
Created attachment 152983 [details] JS_intellisense_dropdown NetBeans IDE Dev (Build 201503300001) I'm experiencing rather frequent problems with the performance of intellisense in JavaScript editor - after pressing Ctrl+SPACE in the middle of some lengthy variable dropdown with known names rather frequently appears in 10+ seconds. Sometime it appears immediately. I'm attaching selfsampler. Note: script is rather long (4500+ lines of code) and is included within MAVEN project. NPSS show much time is spent under org.netbeans.modules.web.jsf.index.JsfCustomIndexer$Factor.scanFinished() I noticed 'JSF' staff in performance-problem related stack in "background scan" of maven projects, so this can be related. More info here: https://netbeans.org/bugzilla/show_bug.cgi?id=250833.
According to the snapshot the problem is in FaceletsLibrarySupport. The code completion is waiting for finishing query from the FaceletsLibrarySupport that is run from EditorParsingLoop. The code completion is trying to parse the source again (probably change in the editor) and this thread can not parse it because the previous EPL have not finished yet.
This is strange. In the NPSS the scanFinished takes 4,8s. But the major part of this time is spent in: org.openide.util.lookup.SimpleProxyLookup$ProxyResult.updateLookup() 2,218 ms org.openide.util.lookup.SimpleProxyLookup$ProxyResult.updateLookup() 2,091 ms Can you share the project for testing?
Tomasi, do you think this is slow FS and/or lookup problem? Is there a problem in scanFinished of JSF?
There are several things which are wrong in the snapshot. 1st) The JS code completion JSIndex.query() should not call QuerySupport when it's cancelled - should be now possible using new CancelSupport in the CSL. 2nd) The QuerySupport refreshes all indexes for given edited file, probably it may be enough to update just the required index. On one side it will help that the JSF indexer is not called by JS but on the other side the file will be processed several times (each time by different indexer - which is slower, the final time is longer but in it blocks for smaller intervals). 3rd) Finally the JSF updates single file for ~ 5 sec which is not acceptable. The problem is visible on the fact that from the single scanFinished - called for single source root it ends with 41 calls of CacheFolder.getDataFolder() - data folder is a cache for source root. So it lost a context (1 root) and reinvented some artificial one (41 roots). Just this degradates the performance 41 times. 4th) Not sure if the JSF indexer checks Context.isCancelled() and ends as soon as it's cancelled.
One minor fix: f74f554d3408. Cancellation of JSHints before query: 931a0e783f14.
Reporter can you share the project for testing? That would really help us. Also feel free to test whether there is an improvement for you once the latest changesets are propagated to the dev build.
Sorry, project is private property of my company - therefore I cannot share it. Of course I'll check changes as they are available and report back.
Integrated into 'main-silver', will be available in build *201508130002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/f74f554d3408 User: Petr Hejl <phejl@netbeans.org> Log: #251571 - Intellisense autosuggest drops down in 10+ seconds
Any feedback on this? Did the recent changes (availabe in daily build) improve anything?
Created attachment 155394 [details] js-dropdown-intellisense.nps
Just rechecked - it appears that problem still present in some form. Steps I've performed: 1. Opened projected. Dropdown with intellisense suggestions appear rather quickly both during initial background scan and after it finished 2. I modified some files - still OK 3. I've "clean build" one of the modules in my multi-module MAVEN project - after that drop down started to appear in around 5 secs. Same timing all the time one after another with any modifications to files - just pressing Ctrl+Space after '.'. Selfsampler for that test is attached. I tried reproducing the same once again with clean restart of NB. Timing was OK that time - so I can't tell what actions exactly are causing the problem.
Too risky for 8.1.
Hopefully this should be fixed in web-main 195ccfb318ca. Reporter can you test it once it is in the daily build?