Hi,
again sorry for morning confusion.
After couple months with PDT and DLTK code base I see many performance
problems, which cannot be fixed without cooperate with DLTK team and/or modify
API/architecture .
TI - Type Inference
CA - Code Assist
DOMAst - old ast, used by formatter, syntax highlighter and many others ui
elements. Not persisted.
AST/Compiler AST - second ast, based on DLTK ast.
1. Imports: in theory PDT registering in model all imports. But, while
resolving references (for example in TI or CA), AST is required to detect
aliases. Since 5.6 problem will grow up, because will be possible to import
function and constants.
To fix this, we require bug 437856 [1]
2. PHPModelUtils: very useful and complex class, highly used while TI, but not
designed to use with TI :P. Examples:
a) White TI, IContext subclasses can contain SourceModule, ModuleDeclaration
(AST), namespace name etc.. But methods in this class isn’tt using this, so
many times they manually asking for source_module, namespace name… by AST or
model traversing.
b) Sometimes they are using IContext, sometimes IModelAccessCache, sometimes
only type hierarchy, sometimes nothing like in traits [2]
3. Bindings: Now available for DOMAst only, and with very generic
implementation. If I need IType from MethodInvocation:
a) Traverse compiler ast to find IContext and corresponing ASTNode
b) Run TI, with all performance problems (again many ask for ModuleDeclaration
and traversing over it).
c) Cache It for concrete AST node
If IMethod/IField is required, collect all fields and methods by PHPModelUtils
JDT works different:
a) Binding resolver, always contain map DOMAst => CompilerAST (built while AST
convert) - I’m still working on converter
b) Contexts are not required, so probably we should build and cache context
while ast convert
c) Bindings are also cached on corresponding AST nodes and reused later (here
we need small DLTK modification)
We also should allow to get IBinding without DOMAst. Just like in JDT.
4. IModelAccessCache: Nice idea, but if TI traverse over more than one
SourceModule, current implementation it’s usable only for superClass hierarchy.
Maybe like attributes in IBuildContext
5. PDT extensions, any: They are not able to cache own informations while TI.
Would be nice to extend PDT or DLTK for this use case. Maybe like attributes in
IBuildContext ?
6. CodeAssistCompanion: Duplicate super hierarchy cache. This class should
provide IModelAccessCache, and share it between contexts.
7. Traits: horrible to debug, nightmare to implement ;). Its not cached, not
indexed, and not persisted in model. PHPModelUtils many times, have to traverse
over AST to detect it, next traverse to collect it, and never cache it.
Fortunately they are still not popular, but later they will degrade
performance. I asked DLTK team in [1] how it should be implemented. Maybe
instead of IImportDeclaration could be IMixinContainer / IMixinDeclaration /
IMixinDetail
8. Array dereference: Now stored on each dereferencable node. So it’s not
possible to provide one dedicated TI Evaluator and cache it. We should use
ArrayAccess for this, like JDT :P.
9. Annotations: Still not standard in PHP, but probably they will be part of
PHP6/ng and we should start thinking about it. DLTK haven’t annotation support
yet. See IAnnotable in JDT
I have also other ideas, but this simple list is most important for now and
future.
Sorry for my english :P
[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=437856
[2] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=430316
--
Dawid Pakuła
+48 795 996 064
w3des.net
ul. Grabiszyńska 108/10
53-437 Wrocław
NIP: 894-293-95-95
REGON: 340769757
_______________________________________________
pdt-dev mailing list
pdt-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/pdt-dev
