10 Tips for a Speedy Zend Studio

August 12, 2013

Zend Studio

This article applies to:

[ Zend Studio ]
[ All operating systems ]


As a PHP developer, you work  with your favorite IDE for eight hours every single day, so it is absolutely necessary to understand what can be achieved by all the features Zend Studio provides – and what should be avoided. I’d like to quote Roy Ganor, Former Project Lead Zend Studio, who said “You have to master your IDE!”

It’s very important to understand how Studio works and the best way, from the the IDE’s perspective, to set up (large) PHP projects. Below is a list of ideas we have collected explaining a variety of different ways  to improve Studio’s performance. Of course, not all tips work for everyone as it always depends on the project infrastructure.


1. Don’t Use Remote Projects

This is probably the most important tip. A lot of Studio users complain about the performance, but they are often using SSH, FTP, or similar  connections for sharing the source code. In this scenario, every action by Zend Studio has to be executed over protocols that are best suited for file download/upload, but not for efficient random file access. Of course, with a remote project setup, a build can take some time. For example, when creating quite a large project (including the complete Zend Framework and some other PHP frameworks – about 1.2 million lines of code) via the Remote System Explorer and SSH, the subsequent project build will take more than 40 minutes. This is, of course, too much time for the user. However, from the program’s point of view, every single line of code needs to be analyzed and validated – and there are a lot of validating and analyzing tools enabled by default in Zend Studio.

To address this problem, we introduced a new workflow called Remote Server Support. To use this functionality, you can set up a new PHP project from a remote server or you can enable Remote Server Support in your existing project’s properties. This will copy the selected project files (possibly only the PHP sources as non-PHP content can be filtered out) from the remote server to the local system. This can take some time, but it has to be done only once.  Every new or modified file will be uploaded to the server automatically by default. Using Remote Server Support will decrease the project build time significantly. For example, the large project mentioned above will be built in about 5 minutes (as opposed to 40 minutes).

An additional advantage of the new workflow is that it will also work with PHP projects which use a version control system, for example SVN or CVS (Git and Mercurial are also available as separate plugins). First, a regular PHP project with version control has to be created and the source files need to be checked out locally. After that, Remote Server Support can be enabled. Since the project files now reside locally, you can work with them using version control. On the other hand, the files on the server are up-to-date, because they are being handled by Remote Server Support and every change, either from manual editing or coming from the version control system, will be propagated to the defined remote location.

2. Always Use the Local Workspace

While Eclipse (and Zend Studio) can work with a workspace that is located on a shared location in the network (CIFS, NFS, etc.), it is not recommended to do so. For a PHP project, most of the project’s service information is written into the workspace. If the workspace access is performed through a connection that is prone to synchronization and concurrent read/write problems, all kinds of issues may arise. Such issues are not always consistent and are usually hard to diagnose. Therefore, we always recommend putting the workspace on the local disk. However, projects may usually safely reside on a remote location that is governed by the operating system (mounts of a network share), under the condition that the network connection is reasonably fast.

To change the workspace location, go to File | Switch Workspace | Other.

3. Master Your Buildpath

5 minutes for the project build might be reasonable for a large project, but it is possible to decrease the time further. By default the complete project is in the Build Path, so every file is parsed. Remove log files, images or complete folders from thePHP Build Path and you’ll see the performance improve. In projects that have extensive use of the JavaScript code, you should also consider adjusting theJavaScript Build Path.

4. Split Your Project

Imagine you have a PHP project based on Zend Framework (ZF). The intuitive way to set up the project would be to add the ZF library to the project’s PHP Include Path. This would mean that on every rebuild of the project, the ZF files are also built again.

This is not always necessary, especially if you have more than one project based on Zend Framework. Instead you can create a separate PHP project called, for example, “ZF Library” and import the ZF library of your choice to this project. Now you have the folder “Zend” in your project, and you can add the project “ZF Library” to the PHP Include Path of your master project. On a rebuild of the master project the ZF files will not be processed but they can be used in Content Assist, code navigation, etc. Additionally, the “ZF Library” project can be added to the list of referred projects (Project | Properties | Project References) so that it opens with the master project automatically.

Huge performance gains can be achieved by splitting the project, since in most projects the frameworks are the biggest part, but they are often only slightly (if at all) modified.

5. Filter Unneeded Resources

In the project tree some resources are available which are not necessarily needed for the development process such as images, logs or cache directories. These directories should be excluded from the Build Path (see tip 3), and can also be filtered out from the PHP Explorer view completely. To do so, go to Project | Properties | Resource | Resource Filters and add the appropriate filters. The irrelevant resources are not displayed any more in the PHP Explorer view ,and they are ignored during the refresh process. This causes the development processes to become faster.

6. Validate Only When Necessary

On every project build, each file will also be validated. Examine the validators, which can be also configured per project. Disable everything you do not want to validate. For example, if you do not need the XML validation, disable the relevant validator. This is especially important if you have split a large project into libraries and main code (see tip 4). For example, you should consider completely disabling the validation of the Zend Framework Library project in a ZF based project. Since you are probably not interested in warnings from ZF, so there’s no need to analyze these files. To change the validation settings, go to Project | Properties | Validation.

7. Only Validate on Demand

If you consider the validation feature essential to your development and don’t want to disable validation of your project, you have the option to start the validation manually. To do this, you should enable project specific settings in Project | Properties | Validation and uncheck the Build option for the validators. Now no validation is done automatically during the project build. However, it can be run manually by choosing Validation from the context (right click) menu  of a PHP project or even of a single directory or file.

8. Only Analyze the Semantics When Necessary

Using the same example as in tip 6, the Zend Framework Library does not need Semantic Analysis since we trust that the ZF team is developing high quality code. Therefore, this feature can also be disabled for “library projects”. To do this, go toProject | Properties | Semantic Analysis and mark the Enable project specific settings checkbox and unmark Enable Semantic Analysis.

9. Close Anything That Is Not Needed

Each view that is open uses system resources and is therefore very time consuming, even by itself. Therefore, you should close all unused views. Consider whether views such as the Console or the Tasks view are relevant for your work. Also close the projects that you are not working with. Each project’s model consumes some portion of RAM, and the bigger the project, the more space. This is very similar to a regular writing desk; you need to clean it from time to time to create room for new things on it.

10. Modify Zend Studio Startup Settings

In the Zend Studio interface it is possible to monitor how much Java heap space is used by the application. To do so, enable the option Show heap status in the Zend Studio Preferences by going to  Window | Preferences | General (in MacOS X go toZend Studio | Preferences | General). The heap status now appears in the application’s status bar. If you see that you quickly run out of memory (for example during a project build) you should consider increasing the default Java heap size. This can be done in the file ZendStudio.ini located in the Zend Studio installation path. Search for the –Xms and –Xmx parameters:

  • Xms – The initial amount of memory to allocate for Java heap space.

  • Xmx – The maximal amount of memory that is allowed to be used for Java heap space.

These values can be increased, but be aware that you are limited by the physical RAM of the system. Even for very complicated projects 512M Xms and 1024M Xmx should be enough.

2 Responses to “10 Tips for a Speedy Zend Studio”

  1. David Says:

    I figured out that on Ubuntu Zend Studio is running much faster when using Oracle Java 7 instead of the default OpenJDK.


  1. Sunny Blog » PHP In Case Of - August 26, 2013

    […] http://devzone.zend.com/3291/10-tips-for-a-speedy-zend-studio/ […]

Leave a Reply

You must be logged in to post a comment.