[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] Performance issues using IType interface
|
Hi, Stephan
I have found the solution to my problem by studying why
IndexBasedHierarchyBuilder.build(boolean) works fast. It turns out that
when I iterate over types in a jar, the first call to IType (e.g.
IType.isInterface()) results in creating new ZipFile object for each
type. That can be easily prevented by
JavaModelManager manager = JavaModelManager.getJavaModelManager();
try {
manager.cacheZipFiles(this);
//All build over jars goes here
} finally {
manager.flushZipFiles(this);
}
JDT works fine and fast. Caching ZipFile objects makes all the difference.
The only concern remaining now is that JavaModelManager is not a part of
API. May I request to consider providing API methods for doing similar
searches?
Thank you.
Best regards,
Slava Kabanovich
On 06/06/2015 08:32 PM, Slava Kabanovich wrote:
Hi, Stephan
Thank you for the reply.
> What requests exactly to you make?
For instance, the very first call IType.isInterface() takes too much
time. If after that I call any other methods of IType they perform
much faster. That is probably because creating element info takes much
time as it probably prepares data for all requests to IType.
Suppose, I need to look into all classes, but i know that I do not
need interfaces and abstract classes, only concrete classes. Then, I
try to be smart and get done with interfaces by a single check
IType.isInterface(). I expect it to be much faster than getting all I
need for a concrete class. But it does not work as expected. As I have
said, (the first) call to isInterface() takes almost as long as
everything else I need to get from a concrete class.
> Not sure what you mean by Java build, since org.eclipse.jdt.core
does implement building Java programs.
I may be mistaken, is not Java building implemented with packages
org.eclipse.jdt.internal.core.jdom and *.internal.compiler.* packages?
With 'org.eclipse.jdt.core' I meant not plugin (yes, the plugin
implements Java build), but package that includes IType and other
handles for querying Java model. When Java builder completes, element
info for IType is not yet created. Then I conclude that Java builder
does not need requesting anything from IType and uses the internal
model that is more efficient.
> Also, I'm not sure I understand what exactly your tool is doing?
It is ok with incremental building, certainly I do not need looking
into a jar at every build, but when a project is imported into
workspace, the full build is performed for it, and Batch tool needs to
determine which jars are Batch archives. Unfortunately, there is no
required resource like batch.xml (it may be present, but is ok to be
missing). So I do not see another way than scanning, just once, the
jar in search for Batch artifacts. If none found, I mark the jar as
'not a Batch archive', and it is ignored after that.
The same with CDI 1.1. While in CDI 1.0 archives resource beans.xml
was required, it is not so since 1.1.
Once more, the performance issue is critical for the case of importing
into workspace a large set of projects with many dependencies. It may
be critical also at workspace refresh if dependencies are changed
(e.g. versions of all jars are changed).
>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)?
In CDI 1.1+, there are many bean defining annotations and most
confusing is that they include custom (defined by application) scopes
and stereotypes, which the tool may either collect as the result of
build, or by checking annotations found at the type during iteration.
>Or just use a subtype hierarchy of a well-known interface?
At present, in Mars M7, when I start 'Open Type Hierarchy' for IType,
it takes about 1 minute to show in the view. In Luna it took only a
few seconds.
>Have you seen the following API?
>org.eclipse.jdt.core.JavaCore.newTypeHierarchy(IRegion,
WorkingCopyOwner, IProgressMonitor)
Thank you, I will try it to see if it may give gain in performance.
Best regards,
Slava Kabanovich
On 06/06/2015 05:39 AM, Stephan Herrmann wrote:
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
_______________________________________________
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