[
https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292066#comment-17292066
]
Matthias Bläsing edited comment on NETBEANS-5380 at 2/27/21, 9:50 AM:
----------------------------------------------------------------------
Thank you for the explanation - with the generated projects indeed I found,
that the SimpleFileOwnerQueryImplementation will normally return the wrong
project. With this in mind I reverted the question: How could we prevent
netbeans from recognizing the legacy projects when MX support is present?
I came up with this:
[https://github.com/matthiasblaesing/netbeans/commit/460042be723b28b430f88c77c1ee7ab18f364892]
The problem from my POV is, that
org.netbeans.modules.project.ant.AntBasedProjectFactorySingleton will recognize
the ant based project and legacy project support kicks in. But NetBeans
supports multiple projects per project and will default to the one with the
ProjectFactory of the lowest position. So two thing are done in the above patch:
# org.netbeans.modules.java.mx.project.SuiteFactory got a position and that
position is lower than the one from AntBasedProjectFactorySingleton
# The factory was modified, to detect MX project not only for the current
directory, but also two levels up
What do you think? I'll switch to a build with this merged and see if it does
what I expect it to do.
[edit]Totally unscientific check:
* had angular-tour-of-heros open (puts medium load onto the indexer)
* opened an MX project (regex from graal project): the main regex project
_and_ the two subprojects (com.oracle.truffle.regex and
com.oracle.truffle.regex.test) where recognized
* I opened regex and got normal java code completion and error reporting (so
looks right)
* indexing is still not fast, but it is back to the normal speed. Now the
JsIndexer is again the most significant part of the indexing
was (Author: mblaesing):
Thank you for the explanation - with the generated projects indeed I found,
that the SimpleFileOwnerQueryImplementation will normally return the wrong
project. With this in mind I reverted the question: How could we prevent
netbeans from recognizing the legacy projects when MX support is present?
I came up with this:
[https://github.com/matthiasblaesing/netbeans/commit/460042be723b28b430f88c77c1ee7ab18f364892]
The problem from my POV is, that
org.netbeans.modules.project.ant.AntBasedProjectFactorySingleton will recognize
the ant based project and legacy project support kicks in. But NetBeans
supports multiple projects per project and will default to the one with the
ProjectFactory of the lowest position. So two thing are done in the above patch:
# org.netbeans.modules.java.mx.project.SuiteFactory got a position and that
position is lower than the one from AntBasedProjectFactorySingleton
# The factory was modified, to detect MX project not only for the current
directory, but also two levels up
What do you think? I'll switch to a build with this merged and see if it does
what I expect it to do.
> 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
