Please use the Apache issue tracking system for new NetBeans issues ( !!

Bug 231282

Summary: GoToType took 144227 ms.
Product: cnd Reporter: Egor Ushakov <gorrus>
Component: Code ModelAssignee: Andrew Krasny <akrasny>
Status: RESOLVED FIXED QA Contact: issues <>
Priority: P3 CC: misterm
Version: 7.4Keywords: PERFORMANCE
Target Milestone: 7.4   
Hardware: All   
OS: All   
Whiteboard: EXCEPTIONS_REPORT perf-profileme
Issue Type: DEFECT Exception Report: 201411
Attachments: nps snapshot

Description Egor Ushakov 2013-06-14 15:22:50 UTC
This issue was reported manually by gorrus.
It already has 3 duplicates 

Build: NetBeans IDE Dev (Build 201306102301)
VM: Java HotSpot(TM) Client VM, 23.21-b01, Java(TM) SE Runtime Environment, 1.7.0_21-b11

User Comments:
gorrus: go to type

gorrus: c and java projects opened

gorrus: go to type

Maximum slowness yet reported was 144227 ms, average is 62335
Comment 1 Egor Ushakov 2013-06-14 15:22:58 UTC
Created attachment 135808 [details]
nps snapshot
Comment 2 Andrew Krasny 2013-07-24 12:47:02 UTC
One of the possible reason is that CppTypeProvider (possibly) didn't see that the task was cancelled... 

Fixed in
Comment 3 Andrew Krasny 2013-07-24 21:52:05 UTC
Another problem is that current implementation of CppTypeProvider doesn't use the possibility to return a partial result. This means that no results passed back to the infrastructure until the whole search is complete (that is why we see this slowness alarm).

The fix is to use pendingResult() call to notify the infrastructure to call computeTypeNames() again.

There are some notes though:

- the infrastructure doesn't handle correctly the situation when computeTypeNames() returns while the result remains empty (because no result is ready yet). Even if pendingResult() was called, a dialog will display "<No results found>" instead of a message with a 'Cancel' hyperlink. [This situation is currently handled in the fix (on the client side, in CppTypeProvider). But this could cause a slowness alarm if time of getting first results exceeds a threshold]

- There is no any visual indication of whether the search is finished or not. But this should be implemented on the infrastructure side.

- javadoc states that computeTypeNames is always called twice - first time with a current project, the second one is with context.project == null. This is not implemented this way (at least at current moment). Now context.project is *always* null. IMO this is OK. But if the behavior is changed, the possible impact could be that we will search through the same (current) project twice.

Comment 4 Quality Engineering 2013-07-26 02:48:40 UTC
Integrated into 'main-silver', will be available in build *201307252300* on (upload may still be in progress)

User: Andrew Krasny <>
Log: Bug #231282 - GoToType took 144227 ms.
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo