Crafting a Better PHP Build Process on Windows – Part IV

by Garrett Serack on June 23, 2009 07:12pm

In the previous post, I discussed what it took to use PGO on the Windows PHP build. That led to me building automated build scripts...

Automation as the root of all evil

"Anything that can be done for you, automatically, can be done to you, automatically." - David C. Wyland

First, I had to get the entire dependency stack into the mix. While some of the dependent libraries had VCProject files, some didn't. Worse, even if they had them, you couldn't tell with a degree of certainty that they were compiled with the same settings which would enable them to take advantage of PGO optimization.

I began taking each project, updating (or creating, using the Trace and mkProject tools) the Visual C++ project files that would use the same settings as the rest, and eventually came up with a solution file that had 74 projects in it - some of the projects generated more than one binary.

Next, I had to actually automate the process of creating the vcproject files. Once you've got the right dependencies, the PHP build process cranks out over 30 binaries when you include the PHP extensions that get built as part of the core. 

After what seemed like a million compile-verify-tweak iterations, I had the tools that could generate VCProject files for the core PHP and all the extensions, provided it was all in the right place.

Next I wrote a .cmd batch script that went step-by-step, checking out the source, compiling the dependent libraries, building the PHP makefile, compiling PHP like the community did - and logging what it was doing, then switching to instrumentation, rebuilding the dependencies again, building the stack, PGO training it with test data and some applications (WordPress, MediaWiki and phpBB) and then relinking it with optimization.

I got the .cmd script almost working, but it was fairly fragile.  At that point I decided to switch batch scripting strategies and, in about a week, rewrote the batch script in JScript, which was far more flexible, and a lot more reliable.

What's next...

"The future always arrives too fast... and in the wrong order." - Alvin Toffler

During this process, I tweaked the build process that is generated quite a bit, adding in a few more applications to the PGO training, which cranks the performance up more and more.

Now, I can add in more scripts to assist with the training pretty trivially, but it still takes some effort to package up an entire application like MediaWiki or WordPress and include it into the build process. 

Even once I've added in an application, I end up doing a whole slew of comparative testing to see what impact it has on the final executables.

As time goes by, I'm sure there will be more tweaking to be done but, in all likelihood, any significant performance gains are going to be the result some modification of the PHP codebase itself.

Comments (0)

Skip to main content