[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-dev] Performance issues using IType interface
|
Hi Slava,
A few points in your description are not clear to me, so it's difficult to advise.
Questions:
> At present this is implemented with requests to IType interface.
What requests exactly to you make?
Creating an IType handle has virtually no cost.
Some requests require to read and analyze the underlying compilation unit or class file etc.
> makes one to assume that Java build uses internally more efficient model than org.eclipse.jdt.core.
Not sure what you mean by Java build, since org.eclipse.jdt.core does implement building Java programs.
Also, I'm not sure I understand what exactly your tool is doing? Why do you have to inspect all
entries of all jars in the classpaths? When speaking of incremental buildings I'd assume
inspecting all compilation units in (affected projects in) the workspace should be enough.
Why isn't it?
Have you considered, instead of iterating lot's of potentially irrelevant elements,
to perform a search (e.g., for all types with a given annotation)? Or just use a
subtype hierarchy of a well-known interface?
If a lot of hierarchy lookup is needed, perhaps doing this in one big bulk instead of
thousands of individual invocations might also speed up things.
Have you seen the following API?
org.eclipse.jdt.core.JavaCore.newTypeHierarchy(IRegion, WorkingCopyOwner, IProgressMonitor)
best,
Stephan
On 05/27/2015 02:38 AM, Slava Kabanovich wrote:
Hello,
I work on Batch and CDI models for JBossTools in Eclipse. Incremental builders for the models look for types that either implement
some interfaces (Batch), or have bean defining annotations (CDI). At present this is implemented with requests to IType interface.
In a large workspace, with a lot of jars in classpath, at first build (or at a change in class path) jar entries have to be checked
for being Batch or CDI archive, there is no simple way to do that (in CDI since 1.1, CDI 1.0 had required beans.xml that made life
much easier) other than checking all types in jar. Tests show that in average about 2000 IType objects may be checked in one second,
which results in unacceptably long build time for large workspaces. Batch and CDI build take 2 to 3 times longer than Java build. It
makes one to assume that Java build uses internally more efficient model than org.eclipse.jdt.core.
Could it be possible to get faster methods for checking inheritance and annotations? It may be still ok to work with IType interface
for objects verified as Batch artifacts or CDI beans/annotations, but it is of great importance to be able to quickly rule out
irrelevant types. Could you please advise me already existing ways to solve this problem, or consider implementing in JDT new high
performance requests?
Thank you.
Best regards,
Viacheslav Kabanovich
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jdt-dev
