[
https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17288064#comment-17288064
]
Matthias Bläsing commented on NETBEANS-5380:
--------------------------------------------
The core question: Why is _SimpleFileOwnerQueryImplementation_ good enough for
every project in netbeans, but not for MX, because when you look at the
implementation, they follow the same pattern and they _*both*_ come down to:
ProjectManager.getDefault().findProject(file)
The difference I see is, that:
* SimpleFileOwnerQueryImplementation does aggressive caching
* has a special implementation to resolve parent URL
* does not bother to try to find a suite.py
* has some more filtering and handling of project ownership
My gut feeling from a quick look over the code: Dropping the special
implementation of FileOwnerQueryImplementation in the mx project support could
already solve the problem, as from my perspective it brings nothing to the
table, that the implementation in projectui already does.
> 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: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
