[ https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288180#comment-17288180 ]
Jaroslav Tulach edited comment on NETBEANS-5380 at 2/23/21, 7:58 AM: --------------------------------------------------------------------- OK, that'd be ideal. However historically the Graal project provided {{mx netbeansinit}} support which generates 8.2 Ant {{nbproject/project.xml}} projects based on content of {{suite/mx.suite/suite.py}}. They were usually located in {{suite/src/*/nbproject}} directories. My goal with the new {{java.mx.projects}} support is to take over the old system and ignore the old projects if there is a {{mx.*/suite.py}} above. To do that I created own global {{FileOwnerQueryImpl}}. Of course, it is not acceptable to slow down 99% of users because of functionality they don't want. I'll try to marry the two goals. was (Author: jtulach): OK, that'd be ideal. > 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 > Assignee: Jaroslav Tulach > 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