[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Performance Of New JDT Indexer
|
Hi,
Your best bet is to contact the author Stefan for specific queries on the new indexer.
Rest of the JDT Core committers were tied up with the latest Java release.
Note: if someone is interested to get the new indexer (helpwanted category) up and integrate, it would be good.
Regards,
Manoj
Jesper Steen Møller ---11/25/2017 09:24:27 PM---Hello, > On 24 Nov 2017, at 21.19, Roland Grunberg <rgrunber@xxxxxxxxxx> wrote:
From: Jesper Steen Møller <jesper@xxxxxxxxxxxxx>
To: "Eclipse JDT Core developers list." <jdt-core-dev@xxxxxxxxxxx>
Date: 11/25/2017 09:24 PM
Subject: Re: [jdt-core-dev] Performance Of New JDT Indexer
Sent by: jdt-core-dev-bounces@xxxxxxxxxxx
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://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D1w3-2DufZyISbqH8jxYv689Exjm0haAGufdcSvEAgl2HQ4&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=P6Yw4Al7mau6mnX7s4th_lEp1CmZQlT3ECQ0_2RR5mM&s=kiXDub2Wk9ilhFR8C6TuS98waFAnAMdExi5MXjXHj4A&e=
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
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jdt-2Dcore-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=A51zLdywEjS50U7u2UMWvsDIrUGEJ5IDXskL5MxIEjA&m=P6Yw4Al7mau6mnX7s4th_lEp1CmZQlT3ECQ0_2RR5mM&s=C6DA1YRM0stdV5aPqis6SRgFG6PZp3gB_W765oj4wYA&e=
