Performance impact about unquoted strings

[Hermann.Richter@gmail.com]

I asked this question on php.general, but I didn't get any reply. So
I'm asking here now.

As you already know, when an identifier is not found to be a defined
constant, php interprets it as a string.

For example:
<?
$var=hello ;
?>

the "constant" hello is not defined, so $var takes the value "hello".

My question is the following:

I have a large script with several thousands of strings.
In order to reduce the files size, I removed all the quotes from the
strings.

What is the performance impact of this in terms of cpu-time and system
resources required??

I mean, the script will take longer to execute??
will it take more cpu??

Thanks in advance.

[Jerry Stuckle]

Re: Performance impact about unquoted strings

Hermann.Richter @gmail.com wrote:

I asked this question on php.general, but I didn't get any reply. So
I'm asking here now.
>
As you already know, when an identifier is not found to be a defined
constant, php interprets it as a string.
>
For example:
<?
$var=hello ;
?>
>
the "constant" hello is not defined, so $var takes the value "hello".
>
My question is the following:
>
I have a large script with several thousands of strings.
In order to reduce the files size, I removed all the quotes from the
strings.
>
What is the performance impact of this in terms of cpu-time and system
resources required??
>
I mean, the script will take longer to execute??
will it take more cpu??
>
Thanks in advance.
>

Yes, it will take longer to execute and require more CPU. Rather than
just accept the value as a string, the parser has to search through
defined values to see if each string is defined or not. Additionally,
PHP generates a notification for each one. The notification itself can
be turned off, but the error handler still needs to run to find out the
notification is not to be sent.

Additionally, there is no guarantee it will work in future versions of PHP.

Put them back in. Not having them is just sloppy programming. And a
few hundred bytes are not going to make much difference.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Chung Leong]

Re: Performance impact about unquoted strings

Jerry Stuckle wrote:

Yes, it will take longer to execute and require more CPU. Rather than
just accept the value as a string, the parser has to search through
defined values to see if each string is defined or not. Additionally,
PHP generates a notification for each one. The notification itself can
be turned off, but the error handler still needs to run to find out the
notification is not to be sent.

To be a little more precise, PHP would perform two look-ups in the
constant hash-table: once for case-sensititve match, another time for
case-insenstitive match. The overhead isn't that high, but it's
definitely slower than a literal string.

The bigger problem is the chance of a constant being defined under that
name. Not a recommended practice at all.

[Erwin Moller]

Re: Performance impact about unquoted strings

Jerry Stuckle wrote:

<snip>

>
Put them back in. Not having them is just sloppy programming. And a
few hundred bytes are not going to make much difference.
>

Dito.
That is good advise.

And even is this 'remove quotes' trick would give you a speedadvantage, it
is not a good move.
Never compromise the readability of your code for a small gain in speed or
size, unless you have a very compelling reason.

If your script is slow find out WHY it is slow first so you know what to
fix. This can be done easily by using microtime or more elegantly by using
a profiler. (I never needed one with PHP. Simple benchmarking with rude
timerfunctions works just fine to spot the CPU-hungy routines/structures.)

If your script is not slow, don't fix it.

A general word of advise: Never try to outsmart a serious
programminglang uage. You can bet on it the makers of the language did that
for you already in ways you cannot think up yourself.
Do yourself a favor and put clearity of your code in the first place.

Regards,
Erwin Moller