This is a discussion on Performance impact about unquoted strings within the PHP Language forums, part of the PHP Programming Forums category; I asked this question on php.general, but I didn't get any reply. So I'm asking here now. ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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. |
|
|||
|
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@attglobal.net ================== |
|
|||
|
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. |
|
|||
|
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 programminglanguage. 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 |