Author Topic: 'Get Reference' performance problem  (Read 1263 times)

flethuseo

  • Senior Community Member
  • Posts: 177
  • Hero Points: 2
'Get Reference' performance problem
« on: February 18, 2015, 11:50:11 pm »
Slickedit's java context tagging takes forever searching for references when I try to use 'get reference' CTRL+/ for the function 'get' in the sample code below:

It also happens that there are many classes that have a method called get, but it shouldn't be looking for references of those classes.

Code: [Select]
/**
* TODO: Add class description
*/
public class Test {

    public int get(int num)
    {
        return num;
    }
    /**
    * Main entry point for the application
    *
    * @param args List of command line arguments passed to the app
    */
    public static void main(String args[]) {
        // TODO: Add application start up code here
        get(3);
    }

}

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2831
  • Hero Points: 429
Re: 'Get Reference' performance problem
« Reply #1 on: February 19, 2015, 06:17:11 pm »
I've explained this before, so please do search the forum for some other "Go to Reference" related threads.

The answer boils down to the fact that our symbol analysis is not a full compiler, simply a fast parser that grabs declarations.  The cross-referencing is basically an inverted word index on the source files that are scanned.

We do plan on implementing a sophisticated algorithm in a future release to narrow down the number of files that we look at when collecting references to a class member, by taking the intersection of the set of files that contain the symbol's name, and the set of files that contain its class name, and all it's parent classes (and there's even more to it than that...).  It is a very naive understanding of object-oriented to suggest that we only look in the files that directly reference the symbol's class name.  This is actually, a *very* hard problem, especially when you factor in type inference.  Keep in mind that our symbol references engine is built to work for tons of different languages, not just Java.