Just taking five minutes to glance at ClassDependencyIndexCreator, I see a bunch of possible optimizations:
1. For each JAR file, it creates a Map<String,byte[]> of className:classBytes, and then iterating it and creating a ClassFile over each one. Garbage-collection wise, it would be considerably cheaper to do the work as the JAR is iterated. 2. A bunch of uses of TreeMap and TreeSet, where it might be cheaper to use HashSet and sort into a list when done - guessing this is done to sort Foo$Bar below Foo? 3. addDependenciesToMap() appears to actually call ClassLoader.getSystemClassLoader().getParent().loadClass() with a bunch of classes found in a random JAR it is scanning. I have trouble imagining why that would ever be a good idea, or is necessary here, and it definitely could seriously impact performance. Unfortunately with a Git checkout, I don't have the history to figure out why. It looks like it is to determine if the class is part of the JDK perhaps? If so, a much faster test would be to look at the package name - yes, theoretically someone can create their own java.lang package, but that's a corner case, and no matter what, actually loading into the JVM every class seen when indexing is costly both in loading things that will never be used by the IDE, and an incredible number of ClassNotFoundExceptions constructed, probably fairly deep in the stack. -Tim On Mon, Apr 23, 2018 at 3:32 AM, Jaroslav Tulach <[email protected]> wrote: > 2018-04-23 8:40 GMT+02:00 Laszlo Kishalmi <[email protected]>: > > > Dear all, > > > > I just experimented some stuff for that yesterday using bintray API for > > their repositories. I was able to retrieve a list of packages by > > group/artifact ID-s and even query artifacts by package/class names, > though > > the later one might need to use the "I feel lucky!" heuristics, as I > > searched for the new JUnit5 package and that gave me 14000+ matches and > > returned the first 50. > > > Excellent. If you put this query in and change the default for the > download/update of local indexer to "never", I'd be happy. > -jt > > PS: Maybe there will be some bugs, but the current indexer performance is > "buggy" too and a lot! > > > > On 04/22/2018 11:28 PM, Christian Lenz wrote: > > > >> Hey Jaroslav, > >> > >> I think now it is the best time to do the Approach again under Apache 😊 > >> > > > PPS: Probably. It has just one issue: There needs to be somebody to do it. > -- http://timboudreau.com
