[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Understanding and optimizing levels of compilation
|
> Re: 2.
> When building type hierarchies, there is some degree of investigation you
> need to perform in methods so as to find local/anonymous types. When
> computing supertype hierarchies, you do not need to do so.
> Jerome - can you pls double check whether there is some obvious
performance
> issue we would have missed ? Maybe some got addressed in our 3.1 perf
cycle
> already.
I didn't see any obvious performance issue with building fields and
methods. And as Philippe said this is
needed for local and anonymous type hierarchies.
jdt-core-dev-bounces@xxxxxxxxxxx wrote on 10/11/2005 09:04:41 AM:
> Re: 1.
> Aside from produce a resolved DOM AST, this API is also meant to detect
> problems. Unless you run all the stages of compilation, then you may miss
> some of them. I agree that producing in memory classfile is a waste of
> time, but our performance measurements show that this is not that
> expensive. Now, if you have some particular offending scenarii, please
> speak up.
>
> Re: 2.
> When building type hierarchies, there is some degree of investigation you
> need to perform in methods so as to find local/anonymous types. When
> computing supertype hierarchies, you do not need to do so.
> Jerome - can you pls double check whether there is some obvious
performance
> issue we would have missed ? Maybe some got addressed in our 3.1 perf
cycle
> already.
>
>
>
>
> Stephan Herrmann
> <stephan@xxxxx-be
> rlin.de>
To
> Sent by: jdt-core-dev@xxxxxxxxxxx
> jdt-core-dev-boun
cc
> ces@xxxxxxxxxxx
>
Subject
> [jdt-core-dev] Understanding and
> 10/11/2005 02:56 optimizing levels of compilation
> AM
>
>
> Please respond to
> stephan and
> "Eclipse JDT Core
> developers list."
>
>
>
>
>
>
> Hi,
>
> I found a few things odd regarding the level of compilation when the
> compiler is triggered from different components of the JDT.
> I'm wondering about a significant number of control flows that request
the
> analysis and generation of byte code without any perceivable need to
> actually generate byte code.
>
> I think investigation of this issue could perhaps help to further
optimize
> the code.
>
> (I'm working on 3.0.2 code, but from skimming through the CVS I could
> see no significant changes in this issue, correct me if I'm wrong)
>
> Here are two examples where I believe the compiler performs unnecessary
> work:
>
> 1.:
> ===
>
> I'm puzzled about the three boolean parameters to
> org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(
> CompilationUnitDeclaration unit,
>
> org.eclipse.jdt.internal.compiler.env.ICompilationUnit sourceUnit,
> NodeSearcher nodeSearcher,
> boolean verifyMethods,
> boolean analyzeCode,
> boolean generateCode)
>
> When digging into the call hierarchy of this method, I see that each
> invocation of
> org.eclipse.jdt.core.dom.ASTParser.createAST()
> actually requests the compiler to analyze and generate code.
>
> Do I miss something? Is byte code generation actually needed here?
>
>
> 2.:
> ===
>
> Why does the HierarchyResolver request to treat methods?
> The comment says, constructors are needed, but why actually
> does hierarchy analysis require constructors to be processed?
> The line in question (two occurences) is:
> this.lookupEnvironment.completeTypeBindings(parsedUnit, true/*build
> constructor only*/);
> where the formal argument to completeBindings reads
> "buildFieldsAndMethods".
> In fact only one out of nine invocations conditionally passes "false" to
> the
> argument "buildFieldsAndMethods" (SuperTypeNamesCollector).
>
> This is probably less an issue for performance as compared to (1.:),
> but it still doesn't seem right to me.
>
>
>
> I would be happy about any hint, when and why the compiler has to
> perform which tasks. Is there a general strategy behind this or are such
> things decided case-by-case?
>
>
> Just in case you wonder about my reason for asking:
> In our project we are adapting the JDT for a Java language extension
> (ObjectTeams/Java, www.objectteams.org). While extending the JDT
> we must of course understand how it works. I'm quite confident about
> what I understand about the compiler itself by now, but those invocations
> from outside the compiler package still cause some headaches ;-)
>
>
> regards
> Stephan
>
>
> PS: actually, I'm quite happy I chose the JDT as the basis for our
> development
> almost three years ago ;-) I do appreciate your work!
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
