Does PHP Run Faster Without Warnings

Does php run faster without warnings?

I bookmarked an article in which the author did some benchmarks about that ; unfortunatly, it's in french... but here it is (maybe you'll understand some parts of it) : Ne faites pas d'erreur

And here are the numbers, to help people who don't read french :

• 10k notices, with error_reporting and display_errors enabled : 5,162.76 ms
• same, but with display_errors disabled : 136.18 ms
• same, but with error_reporting disabled too : 117.79 ms
• and, finally, after patching the code so it doesn't produce any notice anymore : 19.51 ms

Which means that, yes, PHP code runs faster without notices/warnings/errors, even when those are not displayed nor reported.

Derick Rethans says the same thing in this article : Five reasons why the shut-op operator (@) should be avoided (quoting) :

Reason 3: It's slow (part 2)

Whenever PHP generates an error
message internally, it's processed and
formatted all the way up to the fully
formatted message that can be
outputted straight to the browser.

Only just before it is displayed the
error_reporting setting is checked.
This however, is not related to the
@-operator exclusively.

The error
message is just always fully formatted
before error_reporting is checked—or
display_errors for that matter.

Which is better in PHP: suppress warnings with '@' or run extra checks with isset()?

I ran timing tests for both cases, using hash keys of various lengths, also using various hit/miss ratios for the hash table, plus with and without E_NOTICE.

The results were: with error_reporting(E_ALL) the isset() variant was faster than the @ by some 20-30%. Platform used: command line PHP 5.4.7 on OS X 10.8.

However, with error_reporting(E_ALL & ~E_NOTICE) the difference was within 1-2% for short hash keys, and up 10% for longer ones (16 chars).

Note that the first variant executes 2 hash table lookups, whereas the variant with @ does only one lookup.

Thus, @ is inferior in all scenarios and I wonder if there are any plans to optimize it.

Will removing white space and newline characters from PHP make it run faster?

This has already been discussed some via another question here that you might want to look at: php source code whitespace

Also, while I've never personally made use of it, there appears to be a command "php -w" which removes all whitespace and comments for you, should you want to go that route.

Do PHP notices cause additional server load?

Yes it does affect performance.

You need to fix those issues. As you have clearly mentioned that you have more than 100 notifics. It does cause an overload.

After fixing those, regarding improving the performance, you should also have a look at Alternative PHP Cache which will be useful for you.

There is also a good presentation on APC here on SlideShare.

Is PHP execution any faster with strict standards?

It should be faster..

The simple reason being is that PHP's error triggering system is pretty heavy, and even if E_STRICT errors are suppressed, they still enter the error mechanism (only to be ignored).

But in reality it highly depends on the situation, because I could imagine that working around E_STRICT could in itself also be heavier than the original solution.

Regardless though, using E_STRICT is a smart idea and allows for more portable, future-proof code. However, I would not use performance as a valid reason to start writing strict PHP code.

Does having a lot of if statements degrade rendering speed of php?

Nope. In fact, it'll actually speed it up in most cases (because it's allowed to skip over blocks of code).

The only time large numbers of if statements will slow it down is if the condition you're checking requires processing. An example would be something like:

while (true)
{
    if (count($some_array) == 0) { break; }
    /* some other code */
}

Ever iteration through the loop checks if count($some_array) == 0. That means that every pass, PHP has to go and manually count the number of items in $some_array because it may have changed. This also applies to the stop condition in a for loop. This is because a for loop can always be rewritten as a while loop:

for ([INITIALIZER_ACTION]; [CONDITION]; [POST_ITERATION_ACTION]) { [CODE]; }

is the same as...

[INITIALIZER_ACTION];
while ([CONDITION]) { [CODE]; [POST_ITERATION_ACTION]; }

 

If you're considering merging a bunch of if statements into one: don't, you won't get any benefits. PHP does short circuiting which means that if it reaches a point where it knows what the outcome will be, it'll skip the rest.

For example, consider $a = 5; if ($a > 0 || $b > 100 || $c > 200) {}.

Once PHP sees that the $a > 0 condition is satisfied, the whole statement resolved to true (because of the usage of OR values) and doesn't bother to check $b > 100 or $c > 200.

So to answer your question: unless you have an ungodly number of conditionals that each require complicated calculations or have side effects, you can usually consider the quantity of them to be inconsequential.

However, as others have noted, having too many if statements can reduce code readability. In many cases, if you can remove a conditional without it affecting the behavior of the code, then you didn't need it to begin with.

Performance: or ' PHP

You shouldn't even care about this. It makes no real difference. No practical impact.

http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html

https://speakerdeck.com/dshafik/phpaustralia-2015-php-under-the-hood

---

Lets use the same benchmark data from the post by Mark Smit:

For a real speed benchmarks between quotes you can look at http://www.phpbench.com/

Q: Is a there a difference in using double (") and single (') quotes for strings. Call 1'000x

A: In today's versions of PHP it looks like this argument has been satisfied on both sides of the line. Lets all join together in harmony in this one!

Remove warning messages in PHP

You really should fix whatever's causing the warning, but you can control visibility of errors with error_reporting(). To skip warning messages, you could use something like:

error_reporting(E_ERROR | E_PARSE);

---

Related Topics