Community
Participate
Working Groups
Navigation via Ctrl+Hyperlinks is very slow in medium-sized classes, e.g. LocalCorrectionsSubProcessor. When I hold Ctrl and move the mouse, I see update times of almost a second. Most of the time is wasted in repeated calls to JavaElementHyperlinkDetector#detectHyperlinks(..). The two major factors are: 1. All 4 subclasses of JavaElementHyperlinkDetector perform ICodeAssist#codeSelect(..) again on the same element. 2. ICodeAssist#codeSelect(..) is already quite slow, since it often has to compile large parts of the AST and resolve many bindings (I think not using star imports adds to this). We should consider adding a wrapper around calls to codeSelect and first see if we already have a shared AST available for free. If we find a SimpleName without recovered/malformed parents, we should just use resolveBinding().getJavaElement() and keep codeSelect as a fallback.
I had the idea with the ASTProvider because NLSKeyHyperlinkDetector is blindingly fast in comparison. But that change is risky and needs quite some work. Here's an easy solution with a simple cache that cuts detection time by 4. Fixed in master with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=41549d5533b67c9eeb04bcbc3477e9fa4f5be6ea
