Community
Participate
Working Groups
Inside an DOMVisitor, the request to resolve the binding for a name should be done only when required. If you have some code that starts with: import org.eclipse.swt.graphics.Point; import org.eclipse.swt.graphics.Rectangle; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Control; import org.eclipse.swt.widgets.Shell; import org.eclipse.jface.dialogs.IDialogConstants; import org.eclipse.jface.dialogs.IDialogSettings; import org.eclipse.jface.operation.IRunnableContext; import org.eclipse.ui.PlatformUI; import org.eclipse.jdt.core.search.IJavaSearchScope; import org.eclipse.jdt.internal.ui.IJavaHelpContextIds; import org.eclipse.jdt.internal.ui.JavaPlugin; ... and you have a visitor that does this: public boolean visit(SimpleName node) { Binding binding = node.resolveBinding(); .... return false; } or in the endVisit method, this will trigger lot of binding resolution for node that you don't need. For example, in: import org.eclipse.jface.dialogs.IDialogConstants; you would end up resolving: org org.eclipse eclipse org.eclipse.jface jface etc. You end up resolving 9 bindings when I think only the binding for the import reference is used afterwards.
We can check the obivious cases here but recoding this in general for 3.1 isn't an option. This would invalidate to much code so late in the cycle. Olivier, why do we resolve org.eclipse & org.eclipse.jface. There aren't simply names. And can you please enumerate what the impact is of doing this (speed & performance). We always had the impression that resolving these bindings is cheap since we request the bindings when we build the AST. CC Dani since this might affect editor (sematic highlighting & mark occurrences)
One way to fix this is to avoid iterating over import declarations. This will save lots of accesses and will not impact most of the algorithms.
I did some benchmarking with SEF (which access the binding of all simple names in the CU) and the visist(...) method doesn't show up in the traces for large files (e.g.StyledText) or medium file. Another idea to speed this up (if there is a need at all) a little bit is to do some name comparison upfront. For example in SEF we could check if the name of the node == field name. Other refactorings (extract method, flow analyzer) are visiting simple names but only in the scope of a method.
No action planned for 3.1 here. The call doesn't show up in performance traces and according to Philippe the bindings are already exist in the compiler.