[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [pdt-dev] Continue PDT performance improvements

Hi Kaloyan,

1 - One of most important to reduce AST lookup, should be easy to implement and I hope acceptable by DLTK  team. They are now completely out of resources, so probably someone from us should help them.
7 - Iâm still thinking about best, light and portable model for traits (IMixinDeclaration), each suggestion and later help with implementation are important! I have to check how it was done for other languages - perl6 (EPIC), Scalar IDE
3 - we probably can prepare workaround for this by IEvaluationStatisticsRequestor, small patch to DLTK should also be easy.
2, 4, 6, 8 - changes in architecture will be required, probably with better DLTK integration (like enterNamespace in ISourceElementRequestor). Iâll prepare bugs later (target for pdt 3.4 ,  4.0 or future ?).
5 - We also can implement it in PDT only.
9 - is not yet required. Pending php rfc's [1] [2]. Later we can adopt current JDT annotation model into DLTK.

[1] - https://wiki.php.net/rfc/annotations
[2] - https://wiki.php.net/rfc/annotations-in-docblock

--
Dawid PakuÅa 
+48 795 996 064


From: Kaloyan Raev kaloyan.r@xxxxxxxx
Reply: PDT Developers pdt-dev@xxxxxxxxxxx
Date: 23 czerwca 2014 at 16:03:36
To: PDT Developers pdt-dev@xxxxxxxxxxx
Subject:  Re: [pdt-dev] Continue PDT performance improvements

Hi Dawid, 

Thanks for this summary and your overall dedication on improving PDT in the last months.

What kind of help are your looking for to continue? 
Any doubt that the required changes in DLTK will be accepted? :)

Greetings,
Kaloyan


On Mon, Jun 23, 2014 at 4:14 PM, Dawid PakuÅa <zulus@xxxxxxxxx> wrote:
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


--
Dawid PakuÅa 

ul. GrabiszyÅska 108/10
53-437 WrocÅaw
NIP: 894-293-95-95
REGON: 340769757

_______________________________________________
pdt-dev mailing list
pdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pdt-dev


_______________________________________________
pdt-dev mailing list
pdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pdt-dev