10 Tips for a Speedy Zend Studio

This article applies to:

[ Zend Studio ]
[ All operating systems ]

Overview

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.

Tips

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