One more thought on the classes data structure and I'll shut up. ;-)
It would be nice if the data extracted from common jars could be shared
across projects. That is, JDE shouldn't keep a separate list of the
classes in rt.jar for each project a user has open. Assuming that
the map approach is adopted, this would basically amount to keeping a
collection of maps (one per classpath entry) and sharing items in that
collection across projects. This would require putting a dirty flag
on each map instead of on the project's collection of maps.
Javier and Paul - please let me know if you want help with any of this.
Eric
In message <010301c12408$532e5c10$4173d490@kinnucanp>, "Paul Kinnucan" writes:
: Hi All,
:
: Unless there are any strong objections, I'd like to adopt Eric's suggestion
: and make JDK 1.2 a requirement for the JDE, beginning with JDE - 2.2.9beta1.
: (I have frozen JDE-2.2.8 and plan to release it shortly.) I believe it's
: possible to use JDK 1.2+ to develop for JDK <1.2 anyway by not using JDK
: >1.1 and by using the JDK 1.1 cross-compile option.
:
: BTW, thanks, Eric, for taking the time to do a performance review of the
: JDE's Java code and make specific recommendations for improving the
: performance. Your recommendations are excellent. Javier Lopez has already
: sent me updates that implement some of them and I plan to include Javier's
: updates in JDE 2.2.9beta1. It will be interesting to see if they make a
: perceptible difference.
:
: - Paul
:
: ----- Original Message -----
: From: <[EMAIL PROTECTED]>
: To: "Kevin A. Burton" <[EMAIL PROTECTED]>
: Cc: <[EMAIL PROTECTED]>
: Sent: Monday, August 13, 2001 9:06 AM
: Subject: Re: people using jdk < 1.2?
:
:
: >
: > [java 1 vs. java 2 comments]
: >
: > : Has there been any documentation out about this? I don't see why using
: the
: > : Collections API would increase performance.
: >
: > Yes, a number of articles and book chapters have been written about
: > the cost of acquiring the synchronization lock on java objects. Since
: > every method on Vector/Hashtable is synchronized, and since these were
: > frequently used classes in JDK < 1.2, they quickly become performance
: > bottlenecks. The java 2 collections are not synchronized by default
: > and so do not suffer from this particular shortcoming.
: >
: > The second performance problem I noticed is algorithmic in nature.
: > The JDE builds a list of all compiled classes in your project (>
: > 5,000 in the JDK base -- not counting i18n and so forth -- alone).
: > When determining which class to import, it does a linear scan on this
: > list. Clearly it would be faster to sort the list and then use binary
: > searches for lookups.
: >
: > Other obvious, low hanging fruit include using StringBuffer.append()
: > instead of String concatenation inside of loops, and removing unnecessary
: > synchronized method calls in those same loops.
: >
: > An alternative to using a sort/search loop algorithm would be to replace
: > the list data structure with a Map. In the current implementation, the
: > list is comprised of fully qualified classnames. The search looks for
: > the qualified classname only (the `Map' in `java.util.Map'). Clearly one
: > could precompute the `Map' string when building the data structure and
: > turn the search loop into a simple hash lookup that resolves to either
: > a single String (`Map' -> `java.util.Map') or a List of Strings (`List'
: > -> {`java.util.List', `java.awt.List'}).
: >
: > Eric
: >
:
