[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287809#comment-17287809 ]
Matthias Bläsing commented on NETBEANS-5380: -------------------------------------------- These are the Implementations that can be found in-tree, that are not not test implementations: _apisupport/apisupport.ant/src/org/netbeans/modules/apisupport/project/queries/UpdateTrackingFileOwnerQuery.java_ -> Assoziates nbms/jars built from modules _ide/projectui/src/org/netbeans/modules/project/ui/ProjectsRootNode.java_ -> Associates files under project node with FileOwnerQuery _ide/projectapi/src/org/netbeans/modules/projectapi/SimpleFileOwnerQueryImplementation.java_ -> "Real directory scanning" _java/maven/src/org/netbeans/modules/maven/queries/MavenFileOwnerQueryImpl.java_ -> Associates maven local repository path with open maven project _java/jshell.support/src/org/netbeans/modules/jshell/env/ShellOwnerQueryImpl.java_ -> Selects files from a hashmap Looking at __ _ide/projectapi/src/org/netbeans/modules/projectapi/SimpleFileOwnerQueryImplementation.java_ there is an aggressive Cache for the project association, which is totally missing from _SuiteFileOwnerQueryImpl_. This leads to two questions: * why has MX suite its own _FileOwnerQueryImplementation_ and is not relying on the implementation from _projectapi_? * would it make sense to implement a cache like the implementation from _projectapi_ > Background scanning spends significant time in > o.n.m.j.mx.project.SuiteFileOwnerQueryImpl#getOwner > -------------------------------------------------------------------------------------------------- > > Key: NETBEANS-5380 > URL: https://issues.apache.org/jira/browse/NETBEANS-5380 > Project: NetBeans > Issue Type: Bug > Components: java - Source > Affects Versions: Next > Reporter: Matthias Bläsing > Priority: Major > Attachments: sample1.npss, sample2.npss > > > I opened an angular project into an IDE build from recent master. I observed, > that a very (> 20 minutes) long background scanning times could be observed. > I first used visual VM and then the netbeans internal profiler to try to > narrow it down. > *Profile* > I'll attach two self profiles, both show the same picture, so I'll > concentrate on _sample2.npss_: > There are 9 entries in the self profile, that show CPU times > 190s. From > these 8 are waiting in native code and thus false positives: > - ReferenceHandler > - FileSystemWatchService > - process reaper (3x) > - StreamTerm.Output (2x) > - pool-5-thread-1 (From the trace LSP integration) > The one trace, that is connected to the observed scanning and is in java code > is _RepositoryUpdater.worker._ Breaking this down shows, that, although the > forward calls split into two branches, both hit: > _org.netbeans.modules.java.mx.project.SuiteFileOwnerQueryImpl#getOwner_ > That method is responsible for 178s CPU time. No other FileOwnerQueryImpl > shows up in the trace, and thus this leads me to the conclusion, that this is > fishy. > -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists