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
>
