Re: [PHP] Many Small Files or Larger Utility Files
- Date: Wed, 22 Jun 2016 09:16:32 -0500
- From: Larry Garfield <larry@xxxxxxxxxxxxxxxx>
- Subject: Re: [PHP] Many Small Files or Larger Utility Files
On 06/22/2016 06:38 AM, Christoph Becker wrote:
On 21.06.2016 at 20:26, Larry Garfield wrote:
On 06/21/2016 11:52 AM, Christoph Becker wrote:
However, if there is no bytecode cache available on the production
system for whatever reason, it's still possible to merge all (or some
reasonable subsets of) classes into a single file (a few files) during
True, but in what situation would you not have an opcode cache available
that is not one of:
1) Your PHP version is so out of date you may as well give up, because
it's already insecure.
2) Your webhost is so terrible that the best thing you can do for your
app is to get a new webhost.
Indeed, that's what I would think of, too. However, consider off the
shelf applications. These can either require recent PHP versions
including the availability of certain extensions/features (such as
bytecode caches), or not. If they do, they risk either loosing parts of
their user base ("I don't want to upgrade my cheap webhost contract;
I'll rather switch to another software."), or, even worse, some users
won't update to new versions, and that might fall back on the software
developers/supporters (more "bug" reports, bad reputation if yet another
XYZ site has been hacked).
Of course, in an ideal world there would be no issue, but in practise,
there is. See, for instance, Wordpress, which still runs on PHP
5.2.4+. The recommendation to use PHP 5.6+, is only, well, a
recommendation, which is likely to be ignored by some users at least.
While WordPress could easily enforce PHP 5.6+, the developers don't do
that, quite likely due to the reasons mentioned above.
I dislike to be restricted to old PHP versions, but I also dislike all
those support requests like:
Q: after upgrading to the new version, I'm getting a blank screen
A: please enable debug mode
Q: I get "Parse error: syntax error, unexpected T_FUNCTION …"
you have to upgrade to PHP 5.3+ as described in the manual
According to w3techs.com there are still ~10% PHP 5.2 installations out
there, and PHP 5.5+ is available only on ~30% of servers. That
matches my personal experience. Sad, but true.
Indeed, I am intimately familiar with the chicken-and-egg PHP upgrade
problem; Back in 2007 I ran the GoPHP5 project, which is what finally
broke the logjam and killed off PHP 4.
However, the situation is somewhat different today than it was then.
Container-based hosts that make it easier to opt-in to a newer PHP
version are readily-available. The bumpiness of the ride in upgrading
is FAR less than it has ever been in PHP history. (PHP 7 is slightly
bumpy, but not much, and 5.4->5.6 is nearly unnoticeable.) An
increasing number of PHP projects are doing the right thing and
requiring new versions; Wordpress is, I think, the only project of note
that doesn't require PHP 5.5 in its most recent version (and Wordpress
does run just fine on PHP 7, too). See the recently published stats on
Composer (which measure package requirements, not found-servers):
Those look a lot better than the W3Techs stats. (Lies, damned lies, and
In any case, the OP was talking about newly written code that he's
writing, not a legacy application it sounds like. If you're writing
something new, today, there is *no* excuse to not target 5.5 or later;
any reason you can come up with I would argue is an example of "fire
your manager and/or sysadmin for being negligent." Frankly anything
written new today should be PHP 7+.
And someone sweating about the performance impact of having many include
files should upgrade to PHP 7 before they even ask the question; a PHP 7
upgrade is *the* number one thing you can do for the performance of your
PHP app these days. (At least for things affecting PHP itself; sticking
Varnish in front of your app is also a very good idea, etc.)
Disclaimer: I work for one of the aforementioned cloud hosting companies
(Platform.sh); we offer PHP 5.4, 5.5, 5.6, and 7.0, switchable via one
line of YAML, and most of our "starter kits" now default to PHP 7. End
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php