[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Performance Of New JDT Indexer
|
On Sat, Nov 25, 2017 at 10:54 AM, Jesper Steen Møller
<jesper@xxxxxxxxxxxxx> wrote:
> However, the original design goals didn't actually target on 'faster than the old' for single projects, only but for multiple projects (since it's a per-workspace index, rather than a per-project index). So, in fairness, it guess it should be tested on multiple projects at once. See: https://drive.google.com/open?id=1w3-ufZyISbqH8jxYv689Exjm0haAGufdcSvEAgl2HQ4
>
> The current index has been tuned over many years, and replacing it with something slower seems odd. FWIW, I see a bigger problem in the lack of committer commitment to tune and extend the new index.
> (And there's a size issue for multiple workspaces as well, I guess?)
I ended up adding some more parts to the tests to generate an arbitrary
number of projects and split the set of jars among them. I tested for 1,
10, 100 projects with bundles from :
http://download.eclipse.org/releases/oxygen (excluding source jars).
See : https://github.com/rgrunber/eclipse.jdt.core/tree/index_performance
The new indexer certainly improves a lot going from 1, 10, and 100
projects. (total number of classes found is the same, of course).
However with these experiments, the new indexer still doesn't
outperform the old one. It comes pretty close (~1.5x the average
time of the old).
Another thing I observed is that when the old index is freshly built
the first run is always much (~2-3x) slower. I would guess this
difference is the caching referred to by :
https://wiki.eclipse.org/JDT_Core_Index_Programmer_Guide#Rework_the_model_cache_.28Bug_497513.29
https://bugs.eclipse.org/bugs/show_bug.cgi?id=497513
I'll still continue playing around with this from time to time and get a
hold of others that have worked on it. Perhaps looking into actually
disabling caching (for testing) as opposed to just rebuilding the
project/index every time may yield a better comparison. If anyone is
able to point to some tests showing the new index performing better
than the old one, I'm happy to try them out.
Cheers,
Roland Grunberg
