Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 328966

Summary: Hyperlink detectors slowness causes copy delay
Product: [WebTools] JSDT Reporter: Ian Tewksbury <itewksbu>
Component: GeneralAssignee: Ian Tewksbury <itewksbu>
Status: RESOLVED FIXED QA Contact: Nitin Dahyabhai <thatnitind>
Severity: normal    
Priority: P3 CC: jfanderson2
Version: 3.2.3Flags: thatnitind: review+
Target Milestone: 3.2.3   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch
none
Patch - Update 1 thatnitind: iplog+

Description Ian Tewksbury CLA 2010-10-28 15:08:58 EDT
Both JSDTHyperlinkDetector and JavaElementHyperlinkDetector take upwards of 3 seconds to return a result when the JavaScript type hierarchy is large.  This is due to a grander problem with building the JavaScript type hierarchy that has yet to be solved.  The problem is in the case of these detectors is that they are registered on the CTRL key by default and the CTRL key is also used for copy past operations.  Thus when a user selects an area of JavaScript and then presses the CTRL key to invoke a copy the JSDT hyperlink detector will be activated.  In the case of project with large JavaScript type hierarchy this causes an apparent freeze to the user while the detector calculates all for not because the user is just trying to do a copy.

The end result here is to the user Eclipse will freeze for upwards of 3 seconds when invoking a copy operation using the CTRL+c keyboard shortcut.  This side affect justifies an immediate response, more immediate then addressing the over arching issue of JS type hierarchy performance.

The suggested fix for this is to updated the JSDT hyperlink detectors to only calculate links if the user has not selected an area (like they would during a copy operation).
Comment 1 Ian Tewksbury CLA 2010-10-28 15:10:20 EDT
Created attachment 181985 [details]
Patch

Patch updates the JSDT hyperlink detectors to only run if the selected range is 0.
Comment 2 Nitin Dahyabhai CLA 2010-11-01 13:16:07 EDT
Let's rethink this.  Since we control both the hyperlink objects that are created and what they hyperlinks do, let's move most of the computation into the implementor of IHyperlink#open().
Comment 3 Ian Tewksbury CLA 2010-11-02 10:17:19 EDT
Created attachment 182207 [details]
Patch - Update 1

This updated patch takes a more efficient approach by using the existing AST to determine if a selection is linkable or not.  I implemented an ASTVisitor that dependent on the selections node type will decide if a hyperlink should be generated or not.

Right now i choose ASTNode.SIMPLE_NAME and ASTNode.QUALIFIED_NAME as the two node types we want to generate hyperlinks on.  These choices were made by looking at the node types list and testing out in the editor.  If there are any other node types that should be included let me know.
Comment 4 Nitin Dahyabhai CLA 2010-11-17 17:57:42 EST
Committed, thanks, Ian!
Comment 5 Nitin Dahyabhai CLA 2011-03-17 13:48:32 EDT
*** Bug 337781 has been marked as a duplicate of this bug. ***