[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-debug-dev] Performance of the StandardSourcePathProvider.resolveClasspath() method
|
If you have a specific problem with a reproduceable test case, you should
open a bug report. This mailing list is intended for development/design
discussions.
Darin Wright
Eclipse Debug Lead,
Rational Team,
IBM Canada
(204)934-4114
Gary Karasiuk/Toronto/IBM@IBMCA
Sent by: jdt-debug-dev-bounces@xxxxxxxxxxx
10/15/2005 07:33 AM
Please respond to
"Eclipse JDT Debug developers list."
To
jdt-debug-dev@xxxxxxxxxxx
cc
Subject
[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
_______________________________________________
jdt-debug-dev mailing list
jdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-debug-dev
