[ 
https://issues.apache.org/jira/browse/NETBEANS-5380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293389#comment-17293389
 ] 

Jaroslav Tulach commented on NETBEANS-5380:
-------------------------------------------

Everything seems to work in NetBeans 12.0, 12.3 as well as with [your 
patch|https://github.com/matthiasblaesing/netbeans/commit/460042be723b28b430f88c77c1ee7ab18f364892].
 To reproduce try:
{code:java}
graal/truffle$ mx build
graal/truffle$ mx netbeansinit
graal/truffle$ netbeans --open 
src/com.oracle.truffle.api/src/com/oracle/truffle/api/frame/Frame.java
{code}
and when the {{Frame.java}} file is opened in the editor, press _Ctrl-Shift-1_. 
It always opens the right project. E.g. 
{{graal/truffle/src/com.oracle.truffle.api}} in case of 12.0 and 
{{graal/truffle}} in case of new NetBeans. Thanks a lot for the fix, Matthias!

> 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

Reply via email to