Text configuration files (XML, Yaml, JSON, INI, …) work when the configuration is read once, the software persists in memory, and the application doesn’t exit until the user is done.

This is not what PHP does best. Sure PHP also reads the configuration file “once” but the fundamental difference is that PHP starts and exits dozens, maybe hundreds, of times for a single user using a single application.

The metaphorical equivalent would be relaunching World Of Warcraft every time time a user clicks on something.

I know some of you are thinking “Well that’s dumb. I wrote a game in PHP and the webpage isn’t reloading every time the user clicks…” but break that down: you wrote PHP which renders something the user is experiencing in a web-browser (C++) that may or may not be making Ajaxy calls back to the server (JavaScript) and PHP’s role in this solution is always to start-up, process data, return data, then exit.

For PHP to be the right tool for the right job, it has to be fast. Fast for developers to develop in *and* also fast for end users. (Hooray for PHP7!)

Some clever devs get around configuration performance problems by adding extra steps such as transpiling text into pure PHP before deploying, but do these complicated solutions really serve the PHP developer and the underlying philosophy of how we write code? When it comes to PHP there is a nuanced difference between “performance” and “fast.”

Let’s talk about JSON.

JSON, a “text only” and “language independent” data-interchange format, is currently the cool kid on the block, but from the perspective of JavaScript?

var json = { "this": "is", "valid": "javascript" };

Wow. Talk about language independence. No reprocessing!

The equivalent in PHP:

$php = [ 'this' => 'is', 'valid' => 'php' ];

Tada! No overhead of having to validate, process, and convert to PHP. Is it uglier? Debatable.

To be clear: XML, Yaml, JSON, and friends are fine as documents or as data to be processed by PHP. This is totally normal and sometimes even useful. 😉 Barring that, any reasonable PHP developer must conclude that configuration files cannot be a bottleneck. Not a bottleneck for speed of delivering shippable code, nor a bottleneck for acceptable performance. When choosing anything other than native PHP for configuration you are making a trade-off. Is the trade off worth it? The answer is always no. 1

But the secretary needs to be able to edit the app config live on the server and PHP is too hard for him!

No.

But caching! But Transpiling!

No.

But I like coding parsers!

Cool! Use your powers for docs and data, not PHP configs.

But I secretly want to be a JavaScript, Python, Ruby, C#, Java or anything but a PHP developer!

Uhhh, OK?

[1] Unless you are storing your PHP configs in Apache or Nginx as ENV variables. Then to you madam or sir, I bow down.

I thought Blackfire.io would be able to handle POST the way Xdebug does: Generate a different cachegrind file for every PHP invocation; but alas, Blackfire.io currently only does static webpages, command line, or API calls. In theory I could have used “Copy-As-cURL in your Browser” (and believe me I tried) but in practice the WordPress admin is stateless (no $_SESSION), uses check_admin_referer() all over, making whatever POST action I was copying as cURL useless.

The profiler data gave some bogus results (Ie. a lot of WP-CLI bootstrapping gets flagged as slow) but at least this was better than nothing.

In the future, it would be great if Blackfire Companion had some sort of option to profile “the next action,” or to “start profiler on submit,” or something other than reloading the current page… Ping SensioLabs?

Hackerfarm is a place is located in rural Japan, about two hours east of Tokyo on the Boso peninsula. It’s a cluster of buildings, a lot of shared tools, and a beautiful country setting […] a collection of Japanese and foreign tech hackers who’ve escaped from city life. We’re working together on projects, making life richer for ourselves and for the community who have adopted us. »