[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jdt-debug-dev] Performance of the StandardSourcePathProvider.resolveClasspath() method
|
I'm looking into a problem that one
of my customers is having, where the IDE hangs for minutes. I've
tracked the problem down to this method:
org.eclipse.jdt.launching.StandardSourcePathProvider.resolveClasspath()
This is based on Eclipse 3.0.2.
I see that this method doesn't scale
when the number of projects is high, and then the individual projects have
fairly long classpaths.
One of the things this method does is
build up an ArrayList of resolved classpaths. In the example that I'm working
on this list has already over 7,000 elements, and the run isn't finished.
Most of the entries in this list are duplicates.
Is it valid to not add duplicates to
this list? I was thinking if we kept a hashmap on the side, and didn't
add duplicates to the list, that the speed would be greatly increased.
Also there are cases where the list is searched, using a linear search,
and a hash map would greatly improve those operations.
Comments? Have I posted this to
the right place?
Gary Karasiuk, RAD Performance Analyst
karasiuk@xxxxxxxxxx
TL-969-3985, external: (905)-413-3985
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
