Community
Participate
Working Groups
Build ID: PDT Helios SR2 (2.2.1) as well as PDT Indigo (3.0) CQID:WIND00277026 The following 2 PDT decorator definitions in o.e.pdt.ui: org.eclipse.php.ui.problemsDecorator org.eclipse.php.ui.problemsDecoratorForIModelElement are potentially problematic in terms of performance, because they trigger loading the DLTK Core and UI even if no PHP or DLTK functionality is needed. This is problematic in our scenario, where we load a huge Linux Platform project with > 100k Resources. Somehow the decorators seem to trigger model initialization and store persistent properties, which leads to file access and is thus costly... even if no *.php file is ever visible in the Project Explorer and no PHP / DLTK nature is added to our project. Suggested Improvements: 1.) Improve the Labels of the 3 PDT Decorators such that it's clear which one is which and I can turn off the right ones (today, there's 3 identical labels for the 3 decorators). 2.) Improve the enablement expressions of the 2 resource-related decorators, such that they are only invoked / loaded when a *.php file gets visible / rendered. The DLTK Model / Index should only be loaded when really needed, and only for those files that are visible ! There might be more improvements to make, probably in coordination with the DLTK, but limiting those decorators to PHP files only rather than loading on _every_ file seems the most easy and fastest improvement to make.
Inside the DLTK model, this performance issue is also related to org.eclipse.dltk.core.DLTKContentTypeManager.ResetScriptValidPropertyListener
Digging just a little further, I found this text in the Javadoc comment of org.eclipse.dltk.ui.ProblemsLabelDecorator which php.ui uses as implementation class for the problematic decorators: * <b>Important</b>: Although this decorator implements * ILightweightLabelDecorator, do not contribute this class as a decorator to * the <code>org.eclipse.ui.decorators</code> extension. Only use this class in * your own views and label providers. I don't know why this comment is there, but it might be related to the performance issue we're seeing? - Adding some DLTK people for insight...
It looks like as a workaround, a product builder can disable the problematic PHP decorators by default, by putting this into plugin_customization.ini: org.eclipse.ui.workbench/ENABLED_DECORATORS=org.eclipse.php.ui.problemsDecorator\:false,org.eclipse.php.ui.problemsDecoratorForIModelElement\:false,org.eclipse.php.ui.includepath.problemsDecorator\:false but question is, why are those decorators defined so broadly, and why do they violate DLTK API? What are they meant for, after all? What are the side effects of disabling them?
