[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Performance Of New JDT Indexer
|
Hello,
> On 24 Nov 2017, at 21.19, Roland Grunberg <rgrunber@xxxxxxxxxx> wrote:
>
> I've been playing around with the new JDT indexer and can see it performing a bit better than the older one with some manual tests (through UI). However I'm having difficulty coming up with some basic examples purely through jdt.core API showing it outperform the old indexer. My example is a test that extends
> AbstractJavaModelTests for utility methods and is similar to TypeHierarchyTests.
> They create a single project and attach jar files to the project classpath.
Your test case sounds very reasonable, since it resembles (actually is) a real world scenario.
It's a bit disappointing that the new index is slower than the old, and when I tried your test, I also noticed that the indexing doesn't even saturate a single thread:
real 5m26.159s
user 4m55.806s
sys 0m13.217s
(This was for a project of 794 jar files, just running the two newIndex tests). I wonder what the CPU is waiting for. I would have imagined that better use of the CPU can speed up the index-building significantly, such as parallel reading of JAR files.
The I/O was not a bottleneck either, but I must add that I haven't dug into the code to find out why it's so slow.
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?)
-Jesper
