How can I avoid the engineering mistakes of PDT?

Question

As a developer with enough experience to evaluate a tool, I may say that PDT is very huge in size and slow in performance for a PHP IDE.

It gets bigger by release and exponentially slower by the size of the projects. Add some extra syntax coloring rules and it literally crawls, code completion works randomly and building workspace takes like forever. Java black magic (-Xmx etc) eases the pain a little but that's it.

So my questions are:

1. Why is PDT like this? What design or engineering factors led to its poor performance?
2. How can I avoid making these same mistakes in my own products?

Answer 1

I can't speak to PDT specifically, but in general Java itself hasn't been the cause of performance issues in a long time. Some things that may cause performance problems in general are:

• Core developers testing on very beefy machines, or with very small test data compared to the average user.
• Lots of unnecessary memory being used, leading to swap churn.
• Inefficient (or non-existent) use or prioritization of threading to perform tasks in the background.
• Poor asymptotic complexity of algorithms, that may not be noticeable on beefy machines or small test data (see the first point).
• Poor use of caching/memoization. Needed values are constantly recalculated instead of being saved, or conversely too much is being saved that could be discarded.
• Performance critical sections creating a ton of temporary objects.
• Bugs like memory leaks, race conditions, or other interactions that are difficult to detect with the kinds of unit testing developers typically do, but are much easier to trigger in the field.

As an example, some software I used a long time ago would push the entire save file twice every time it needed to be able to undo an operation. This wasn't an issue unless you had limited RAM, kept the program open a long time, and/or had very large data files. In short, all conditions a customer would hit that a developer is much less likely to. It might be worth performing your own investigation.

Answer 2

There is actually no problem with Eclipse PDT. The reason some users have it very slow is that these users haven't done the important project configuration.

Every project has validators. Many of them can be safely disabled, other are relevant only for a small fraction of the project and irrelevant for the rest. For example, application framework shouldn't be scanned for TODO's, HTML syntax validity, XML syntax validity, PHP errors, and similar. Only the actual project should be scanned.

This needs to be configured per project. Rebuilding workspace then takes up to 5 seconds (if it's a large project).

Here is the suggested performance optimization:

1. Right click project
2. Select properties
3. Select validation
4. Check Enable Project specific settings
5. On any Validator row, click the '...' button
6. Select Exclude Group
7. Click Add rule
8. Select 'Folder or file name'
9. Click Next
10. Select files or folder which don't need any validation (i.e. 3rd-party files in your project).
11. Click Finish
12. Click OK
13. Click OK

Repeat the above for all current validators, or simply disable unwanted validators completely.

In addition, follow the Zend Studio performance optimization. It applies to PDT just as well: http://kb.zend.com/index.php?View=entry&EntryID=480

Portions borrowed from https://stackoverflow.com/questions/783902/excluding-disabling-validation-in-eclipse

Since I believe there is no mistake in eclipse (and PDT), the question no. 2 is not applicable here. Note that PDT is not a PHP IDE. It is a plugin for Eclipse which adds PHP support. Eclipse is a development platform. It's robust, configurable, scalable.

Bottom end: users should be able to configure their projects to use only what they need.