[
https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287809#comment-17287809
]
Matthias Bläsing edited comment on NETBEANS-5380 at 2/20/21, 10:27 PM:
-----------------------------------------------------------------------
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_? Could the implementation just be
removed in favor of the referenced implementation?
* Would it make sense to implement a cache like the implementation from
_projectapi_?
was (Author: mblaesing):
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_? Could the implementation just be
removed in favor of the referenced implementation.
* 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
> 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
