|[pdt-dev] Continue PDT performance improvements|
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 
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 
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  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
 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=437856
 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=430316
+48 795 996 064
ul. GrabiszyÅska 108/10