So I was trying to research a coding standard that I don't see documented anywhere. What is the standard about NULL, TRUE and FALSE. According to the coder module it says to use lowercase because it is faster, but throughout core there is uppercase. e.g. in the system.module (not to mention the trailing comma is missing...) /** * Implementation of hook_menu(). */ function system_menu($may_cache) { $items = array(); if ($may_cache) { $items[] = array('path' => 'system/files', 'title' => t('File download'), 'callback' => 'file_download', 'access' => TRUE, 'type' => MENU_CALLBACK); I know this is a very minor point, but we are trying to match our internal coding standards with that of Drupal. Thanks! Steve Rude
I personally prefer uppercase because it's more consistent with other constants. What source says lowercase is faster? Steve Rude wrote:
So I was trying to research a coding standard that I don't see documented anywhere. What is the standard about NULL, TRUE and FALSE. According to the coder module it says to use lowercase because it is faster, but throughout core there is uppercase.
e.g. in the system.module (not to mention the trailing comma is missing...)
/** * Implementation of hook_menu(). */ function system_menu($may_cache) { $items = array();
if ($may_cache) { $items[] = array('path' => 'system/files', 'title' => t('File download'), 'callback' => 'file_download', 'access' => TRUE, 'type' => MENU_CALLBACK);
I know this is a very minor point, but we are trying to match our internal coding standards with that of Drupal.
Thanks!
Steve Rude
According to this: http://drupal.org/node/121388 lowercase is faster, but we should make a decision, and document it in the coding standard. I just find it confusing for our entry to mid-level developers to have the coder module saying one thing and the code everywhere saying something else... I was correcting them about using lowercase instead of uppercase when I found out the coder module was telling them something else entirely. David Strauss wrote:
I personally prefer uppercase because it's more consistent with other constants. What source says lowercase is faster?
Steve Rude wrote:
So I was trying to research a coding standard that I don't see documented anywhere. What is the standard about NULL, TRUE and FALSE. According to the coder module it says to use lowercase because it is faster, but throughout core there is uppercase.
e.g. in the system.module (not to mention the trailing comma is missing...)
/** * Implementation of hook_menu(). */ function system_menu($may_cache) { $items = array();
if ($may_cache) { $items[] = array('path' => 'system/files', 'title' => t('File download'), 'callback' => 'file_download', 'access' => TRUE, 'type' => MENU_CALLBACK);
I know this is a very minor point, but we are trying to match our internal coding standards with that of Drupal.
Thanks!
Steve Rude
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-877 x 202 http://www.achieveinternet.com
There is a long discussion about this in the coder issue queue (http://drupal.org/node/121388). I personally favor all upcase and don't see any reason to change what is a standard convention familiar to many people without overwhelming evidence of the need to change it. I also have to say that I feel that coder module should not be establishing coding standards for Drupal, but instead these things should be discussed and agreed upon in the community and then coder module implement them. We do have a Coding Standards page in the handbook and I think that should be the closest thing to a canonical reference for Drupal code. - Addi On Aug 27, 2007, at 2:13 PM, David Strauss wrote:
I personally prefer uppercase because it's more consistent with other constants. What source says lowercase is faster?
Steve Rude wrote:
So I was trying to research a coding standard that I don't see documented anywhere. What is the standard about NULL, TRUE and FALSE. According to the coder module it says to use lowercase because it is faster, but throughout core there is uppercase.
e.g. in the system.module (not to mention the trailing comma is missing...)
/** * Implementation of hook_menu(). */ function system_menu($may_cache) { $items = array();
if ($may_cache) { $items[] = array('path' => 'system/files', 'title' => t('File download'), 'callback' => 'file_download', 'access' => TRUE, 'type' => MENU_CALLBACK);
I know this is a very minor point, but we are trying to match our internal coding standards with that of Drupal.
Thanks!
Steve Rude
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations. About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
Hi, in some simple command-line tests I could not find a difference (in php 5.2) true: 1.32612895966 TRUE: 1.38275790215 true: 1.34794092178 TRUE: 1.39009809494 true: 1.34102320671 TRUE: 1.38674616814 true: 1.2856991291 TRUE: 1.27452993393 true: 1.34056401253 TRUE: 1.2749080658 true: 1.31166195869 TRUE: 1.33323001862 true: 1.34053897858 TRUE: 1.27428483963 true: 1.28342199326 TRUE: 1.33444595337 <?php $loop = 0; while ($loop < 8) { $count = 0; $start = microtime(true); while ($count < 4000000) { $test = true; if (true) { $count++; } } echo ' true: '; echo microtime(true) - $start; $count = 0; $start = microtime(true); while ($count < 4000000) { $test = TRUE; if (TRUE) { $count++; } } echo ' TRUE: '; echo microtime(true) - $start; echo "\n"; $loop++; } --mark On 8/27/07, Karoly Negyesi <karoly@negyesi.net> wrote:
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations.
About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
You are outputting in seconds. Sure .06 seconds doesn't sound like a lot, but when you multiply that times 1000 to get milliseconds, it starts to look more substantial... 1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference. Steve Rude mark burdett wrote:
Hi, in some simple command-line tests I could not find a difference (in php 5.2)
true: 1.32612895966 TRUE: 1.38275790215 true: 1.34794092178 TRUE: 1.39009809494 true: 1.34102320671 TRUE: 1.38674616814 true: 1.2856991291 TRUE: 1.27452993393 true: 1.34056401253 TRUE: 1.2749080658 true: 1.31166195869 TRUE: 1.33323001862 true: 1.34053897858 TRUE: 1.27428483963 true: 1.28342199326 TRUE: 1.33444595337
<?php $loop = 0; while ($loop < 8) { $count = 0; $start = microtime(true); while ($count < 4000000) { $test = true; if (true) { $count++; } } echo ' true: '; echo microtime(true) - $start;
$count = 0; $start = microtime(true); while ($count < 4000000) { $test = TRUE; if (TRUE) { $count++; } } echo ' TRUE: '; echo microtime(true) - $start; echo "\n"; $loop++; }
--mark
On 8/27/07, Karoly Negyesi <karoly@negyesi.net> wrote:
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations.
About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-877 x 202 http://www.achieveinternet.com
well, it seems like coin tossing to me. But I haven't let it run all day. in this test, TRUE wins: mark@subtle ~/Sites % php pp/test.php true: 1.26725101471 TRUE: 1.25381183624 true: 1.29299092293 TRUE: 1.26070404053 true: 1.27665114403 TRUE: 1.24824905396 true: 1.31866884232 TRUE: 1.25040316582 true: 1.27103209496 TRUE: 1.2434129715 true: 1.28510403633 TRUE: 1.24616312981 true: 1.29535198212 TRUE: 1.24373793602 true: 1.27827787399 TRUE: 1.22749304771 in this one a tie: mark@subtle ~/Sites % php pp/test.php true: 1.26420211792 TRUE: 1.24726390839 true: 1.25392603874 TRUE: 1.25495100021 true: 1.25082397461 TRUE: 1.24722003937 true: 1.25069499016 TRUE: 1.24976992607 true: 1.25077605247 TRUE: 1.247205019 true: 1.25090909004 TRUE: 1.25059509277 true: 1.30386614799 TRUE: 1.31354403496 true: 1.2652528286 TRUE: 1.25868320465 TRUE wins another one: mark@subtle ~/Sites % php pp/test.php true: 1.23990178108 TRUE: 1.21928906441 true: 1.22088694572 TRUE: 1.21982097626 true: 1.21747803688 TRUE: 1.22024011612 true: 1.21896100044 TRUE: 1.22330522537 true: 1.22763895988 TRUE: 1.2149310112 true: 1.21694612503 TRUE: 1.21505308151 true: 1.21890115738 TRUE: 1.21598815918 true: 1.21745586395 TRUE: 1.21514201164 --mark On 8/27/07, Steve Rude <steve@achieveinternet.com> wrote:
You are outputting in seconds. Sure .06 seconds doesn't sound like a lot, but when you multiply that times 1000 to get milliseconds, it starts to look more substantial...
1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference.
Steve Rude
mark burdett wrote: Hi, in some simple command-line tests I could not find a difference (in php 5.2)
true: 1.32612895966 TRUE: 1.38275790215 true: 1.34794092178 TRUE: 1.39009809494 true: 1.34102320671 TRUE: 1.38674616814 true: 1.2856991291 TRUE: 1.27452993393 true: 1.34056401253 TRUE: 1.2749080658 true: 1.31166195869 TRUE: 1.33323001862 true: 1.34053897858 TRUE: 1.27428483963 true: 1.28342199326 TRUE: 1.33444595337
<?php $loop = 0; while ($loop < 8) { $count = 0; $start = microtime(true); while ($count < 4000000) { $test = true; if (true) { $count++; } } echo ' true: '; echo microtime(true) - $start;
$count = 0; $start = microtime(true); while ($count < 4000000) { $test = TRUE; if (TRUE) { $count++; } } echo ' TRUE: '; echo microtime(true) - $start; echo "\n"; $loop++; }
--mark
On 8/27/07, Karoly Negyesi <karoly@negyesi.net> wrote:
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations.
About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
-- Steve Rude + Lead Developer AchieveInternet (800) 618-877 x 202
I have been told numerous times that it is a big mistake trusting microtime tests. if you want to get /real/ run time results you need to use tools like xdebug. On 8/27/07, mark burdett <mfburdett@gmail.com> wrote:
well, it seems like coin tossing to me. But I haven't let it run all day.
in this test, TRUE wins: mark@subtle ~/Sites % php pp/test.php true: 1.26725101471 TRUE: 1.25381183624 true: 1.29299092293 TRUE: 1.26070404053 true: 1.27665114403 TRUE: 1.24824905396 true: 1.31866884232 TRUE: 1.25040316582 true: 1.27103209496 TRUE: 1.2434129715 true: 1.28510403633 TRUE: 1.24616312981 true: 1.29535198212 TRUE: 1.24373793602 true: 1.27827787399 TRUE: 1.22749304771
in this one a tie: mark@subtle ~/Sites % php pp/test.php true: 1.26420211792 TRUE: 1.24726390839 true: 1.25392603874 TRUE: 1.25495100021 true: 1.25082397461 TRUE: 1.24722003937 true: 1.25069499016 TRUE: 1.24976992607 true: 1.25077605247 TRUE: 1.247205019 true: 1.25090909004 TRUE: 1.25059509277 true: 1.30386614799 TRUE: 1.31354403496 true: 1.2652528286 TRUE: 1.25868320465
TRUE wins another one: mark@subtle ~/Sites % php pp/test.php true: 1.23990178108 TRUE: 1.21928906441 true: 1.22088694572 TRUE: 1.21982097626 true: 1.21747803688 TRUE: 1.22024011612 true: 1.21896100044 TRUE: 1.22330522537 true: 1.22763895988 TRUE: 1.2149310112 true: 1.21694612503 TRUE: 1.21505308151 true: 1.21890115738 TRUE: 1.21598815918 true: 1.21745586395 TRUE: 1.21514201164
--mark
On 8/27/07, Steve Rude <steve@achieveinternet.com> wrote:
You are outputting in seconds. Sure .06 seconds doesn't sound like a
lot,
but when you multiply that times 1000 to get milliseconds, it starts to look more substantial...
1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference.
Steve Rude
mark burdett wrote: Hi, in some simple command-line tests I could not find a difference (in php 5.2)
true: 1.32612895966 TRUE: 1.38275790215 true: 1.34794092178 TRUE: 1.39009809494 true: 1.34102320671 TRUE: 1.38674616814 true: 1.2856991291 TRUE: 1.27452993393 true: 1.34056401253 TRUE: 1.2749080658 true: 1.31166195869 TRUE: 1.33323001862 true: 1.34053897858 TRUE: 1.27428483963 true: 1.28342199326 TRUE: 1.33444595337
<?php $loop = 0; while ($loop < 8) { $count = 0; $start = microtime(true); while ($count < 4000000) { $test = true; if (true) { $count++; } } echo ' true: '; echo microtime(true) - $start;
$count = 0; $start = microtime(true); while ($count < 4000000) { $test = TRUE; if (TRUE) { $count++; } } echo ' TRUE: '; echo microtime(true) - $start; echo "\n"; $loop++; }
--mark
On 8/27/07, Karoly Negyesi <karoly@negyesi.net> wrote:
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations.
About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
-- Steve Rude + Lead Developer AchieveInternet (800) 618-877 x 202
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference.
Even if we disregard the fact that microtime tests have a big stddev, your test is not very convincing: You are using these constants several hundred thousand times whereas Drupal only has 2500+ in its *entire* source code. And of that source code, only a fraction gets to execution. I'd estimate the number of constants that are actually executed on a Drupal page view to about 500, and even that is probably too high. If you extrapolate your results (60ms for 100000), you'll get 0.3 msecs. Besides, a real world server behaves quite different from a desktop machine, especially in such edge cases. Konstantin
Konstantin Käfer wrote:
1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference.
Even if we disregard the fact that microtime tests have a big stddev, your test is not very convincing: You are using these constants several hundred thousand times whereas Drupal only has 2500+ in its *entire* source code. And of that source code, only a fraction gets to execution. I'd estimate the number of constants that are actually executed on a Drupal page view to about 500, and even that is probably too high. If you extrapolate your results (60ms for 100000), you'll get 0.3 msecs. Besides, a real world server behaves quite different from a desktop machine, especially in such edge cases.
Konstantin
Have we established that this is an execution-mode difference? I don't understand why this performance issue would extend beyond the interpreter's conversion to object code.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin Käfer schrieb:
1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference.
Even if we disregard the fact that microtime tests have a big stddev,
We shouldn't do that. The posted results are totally worthless without an error estimate. People, stop wasting everybody's time, read http://drupal.org/node/79237, or preferably an introduction to statistics and a howto on doing experiments in first year phyiscs, then re-do the tests. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG006Afg6TFvELooQRAiEIAJsEhgTnveCuy/oIQwtB3ZoyqVLKUQCgg1D2 b47T4rQcw2YlPiu9EKvrGJk= =gcGC -----END PGP SIGNATURE-----
Fair enough. The only things I would disagree with is that 1) Just because there are only 2500 in the source code doesn't mean that they don't get looped over quite a bit, and 2) my Mac Pro Quad Xeon with 4GB of memory behaves all that much different than the Quad Xeon 4GB webservers that we and our clients have deployed :) The original question came out of the coder module which recommended these changes for better "performance", and I looked into it, and several other projects recommend using lower case for these constants, as well as a couple bugs on the php.net bug list. I actually prefer writing with upper case, so the only point was if there was any real world gain. Here are the links I had found: http://bugs.php.net/bug.php?id=27286&edit=1 http://framework.zend.com/wiki/display/ZFDEV/PHP+Coding+Standard+(draft)?sho... http://drupal.org/node/121388 http://ilia.ws/archives/12-PHP-Optimization-Tricks.html Other PHP software that use lower case true, false and null standard: PEAR Standard - http://pear.php.net/manual/en/standards.naming.php Joomla - http://help.joomla.org/content/view/826/125/ Mambo - http://www.source.mambo-foundation.org/content/view/117/69/ EZ Publish - http://ez.no/ezpublish/documentation/development/standards/php Flyspray - http://flyspray.org/internal:conventions#constant_names OSCommerce - http://svn.oscommerce.com/fisheye/browse/osCommerce/tags/oscommerce-2.2rc1/S... phpMyAdmin - http://phpmyadmin.sourceforge.net/documentation/ Zen Cart - http://www.zen-cart.com/wiki/index.php/Developers_Standards#Naming_Conventio... phpBB - http://area51.phpbb.com/docs/coding-guidelines.html#optimizing And finally, thank you Peter for updating the docs to clarify. Sorry to be a performance nut, but I can't help it. I think a lot of us are a little OCD sometimes :D Steve Rude Konstantin Käfer wrote:
1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference.
Even if we disregard the fact that microtime tests have a big stddev, your test is not very convincing: You are using these constants several hundred thousand times whereas Drupal only has 2500+ in its *entire* source code. And of that source code, only a fraction gets to execution. I'd estimate the number of constants that are actually executed on a Drupal page view to about 500, and even that is probably too high. If you extrapolate your results (60ms for 100000), you'll get 0.3 msecs. Besides, a real world server behaves quite different from a desktop machine, especially in such edge cases.
Konstantin
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-8777 x 202 http://www.achieveinternet.com
Sorry to add more salt to the open wound, but i am with Steve Rude on this one. when it comes to drupal, we should hang onto every chance to improve performance. even small things like changing upper case TRUE to lowercase. as some have mentioned: in a single request drupal might not have enough such cases to make a difference. but when your site receives a lot of traffic, something as small as this might make a difference. On 8/27/07, Steve Rude <steve@achieveinternet.com> wrote:
Fair enough. The only things I would disagree with is that 1) Just because there are only 2500 in the source code doesn't mean that they don't get looped over quite a bit, and 2) my Mac Pro Quad Xeon with 4GB of memory behaves all that much different than the Quad Xeon 4GB webservers that we and our clients have deployed :)
The original question came out of the coder module which recommended these changes for better "performance", and I looked into it, and several other projects recommend using lower case for these constants, as well as a couple bugs on the php.net bug list. I actually prefer writing with upper case, so the only point was if there was any real world gain.
Here are the links I had found:
http://bugs.php.net/bug.php?id=27286&edit=1
http://framework.zend.com/wiki/display/ZFDEV/PHP+Coding+Standard+(draft)?showComments=false#PHPCodingStandard%28draft%29-BooleansandtheNULLValue<http://framework.zend.com/wiki/display/ZFDEV/PHP+Coding+Standard+%28draft%29?showComments=false#PHPCodingStandard%28draft%29-BooleansandtheNULLValue> http://drupal.org/node/121388 http://ilia.ws/archives/12-PHP-Optimization-Tricks.html
Other PHP software that use lower case true, false and null standard:
PEAR Standard - http://pear.php.net/manual/en/standards.naming.php Joomla - http://help.joomla.org/content/view/826/125/ Mambo - http://www.source.mambo-foundation.org/content/view/117/69/ EZ Publish - http://ez.no/ezpublish/documentation/development/standards/php Flyspray - http://flyspray.org/internal:conventions#constant_names OSCommerce - http://svn.oscommerce.com/fisheye/browse/osCommerce/tags/oscommerce-2.2rc1/S... phpMyAdmin - http://phpmyadmin.sourceforge.net/documentation/ Zen Cart - http://www.zen-cart.com/wiki/index.php/Developers_Standards#Naming_Conventio... phpBB - http://area51.phpbb.com/docs/coding-guidelines.html#optimizing
And finally, thank you Peter for updating the docs to clarify.
Sorry to be a performance nut, but I can't help it. I think a lot of us are a little OCD sometimes :D
Steve Rude
Konstantin Käfer wrote:
1326ms vs. 1382ms is 60ms, and when normal page load times are somewhere around 200ms, it makes a substantial difference.
Even if we disregard the fact that microtime tests have a big stddev, your test is not very convincing: You are using these constants several hundred thousand times whereas Drupal only has 2500+ in its *entire* source code. And of that source code, only a fraction gets to execution. I'd estimate the number of constants that are actually executed on a Drupal page view to about 500, and even that is probably too high. If you extrapolate your results (60ms for 100000), you'll get 0.3 msecs. Besides, a real world server behaves quite different from a desktop machine, especially in such edge cases.
Konstantin
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-8777 x 202
-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oleg Terenchuk schrieb:
Sorry to add more salt to the open wound, but i am with Steve Rude on this one. when it comes to drupal, we should hang onto every chance to improve performance. even small things like changing upper case TRUE to lowercase. as some have mentioned: in a single request drupal might not have enough such cases to make a difference. but when your site receives a lot of traffic, something as small as this might make a difference.
If Drupal would adopt such "ideas" the code would be pretty much unreadable. It is much cheaper to buy a faster server than to pay developers to understand obscure code. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG02bJfg6TFvELooQRAv2+AJ9fca/uNXr45wJnXji2h6gHFacpsgCfdPfI Lsxnh0WMHyOBDDCni6BToMQ= =GKjM -----END PGP SIGNATURE-----
We become heroes when we do more, and then we get paid more. ----- Original Message ----- From: "Ken Rickard" <agentrickard@gmail.com> To: development@drupal.org Sent: Monday, August 27, 2007 8:23:12 PM (GMT-0600) America/Chicago Subject: Re: [development] coding standard question We get paid? :-) It is much cheaper to buy a faster server than to pay developers to understand obscure code.
I ran this test just to see what would happen, and here are the results, feel free to test it yourself. According to this test, running a simple loop with one if statement 100k times, you lose about 20ms using uppercase. What is interesting, is that the same test in php5 runs 100ms faster. slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-4.4.7 test.php Time for UPPERCASE: 723.675251007 ms Time for lowercase: 702.354669571 ms slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-5.2.2 test.php Time for UPPERCASE: 622.086286545 ms Time for lowercase: 607.203245163 ms Another interesting stat is that we have 2383 times in a stock drupal 5.1 distribution where we use an uppercase TRUE, FALSE or NULL. Reference: slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r TRUE * | wc -l 629 slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r FALSE * | wc -l 511 slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r NULL * | wc -l 1243 So it does not seem that unreasonable to me that we could potentially get some performance gain by standardizing on lower case true, false and null. Preference aside (me being on the uppercase side), I believe that adding this standard to the drupal standards could potentially give us a small amount of performance increase. I also think the issue should be documented in the coding standard and reflected in the Coder module regardless of the decision. Here is the code for the test: slantview:~ steverude$ cat test.php <?php function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); } $var = true; $time_total = 0; for ($i = 0; $i < 100000; ++$i) { $time_start = microtime_float(); if ($var === TRUE) { $time_end = microtime_float(); $time_total += $time_end - $time_start; } } $time_total = $time_total * 1000; print "Time for UPPERCASE: $time_total ms\n\n"; $time_total = 0; for ($i = 0; $i < 100000; ++$i) { $time_start = microtime_float(); if ($var === true) { $time_end = microtime_float(); $time_total += $time_end - $time_start; } } $time_total = $time_total * 1000; print "Time for lowercase: $time_total ms\n\n"; Thanks, Steve Rude Karoly Negyesi wrote:
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations.
About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-877 x 202 http://www.achieveinternet.com
What happens if you change the initial "$var = true;" into "$var = TRUE;"? Steve Rude wrote:
I ran this test just to see what would happen, and here are the results, feel free to test it yourself. According to this test, running a simple loop with one if statement 100k times, you lose about 20ms using uppercase. What is interesting, is that the same test in php5 runs 100ms faster.
slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-4.4.7 test.php Time for UPPERCASE: 723.675251007 ms
Time for lowercase: 702.354669571 ms
slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-5.2.2 test.php Time for UPPERCASE: 622.086286545 ms
Time for lowercase: 607.203245163 ms
Another interesting stat is that we have 2383 times in a stock drupal 5.1 distribution where we use an uppercase TRUE, FALSE or NULL.
Reference:
slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r TRUE * | wc -l 629 slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r FALSE * | wc -l 511 slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r NULL * | wc -l 1243
So it does not seem that unreasonable to me that we could potentially get some performance gain by standardizing on lower case true, false and null. Preference aside (me being on the uppercase side), I believe that adding this standard to the drupal standards could potentially give us a small amount of performance increase.
I also think the issue should be documented in the coding standard and reflected in the Coder module regardless of the decision.
Here is the code for the test:
slantview:~ steverude$ cat test.php <?php
function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); }
$var = true;
$time_total = 0; for ($i = 0; $i < 100000; ++$i) { $time_start = microtime_float(); if ($var === TRUE) { $time_end = microtime_float(); $time_total += $time_end - $time_start; } } $time_total = $time_total * 1000; print "Time for UPPERCASE: $time_total ms\n\n";
$time_total = 0; for ($i = 0; $i < 100000; ++$i) { $time_start = microtime_float(); if ($var === true) { $time_end = microtime_float(); $time_total += $time_end - $time_start; } } $time_total = $time_total * 1000; print "Time for lowercase: $time_total ms\n\n";
Thanks,
Steve Rude
Karoly Negyesi wrote:
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations.
About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-877 x 202
Very interesting question! Here are the results (look at php5 !?) slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-4.4.7 test.php Time for UPPERCASE: 720.796108246 ms Time for lowercase: 703.890800476 ms slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-5.2.2 test.php Time for UPPERCASE: 617.037057877 ms Time for lowercase: 613.1939888 ms Just for testing sake, I also changed it to numeric 1 and ran it with == instead of === (who uses === most of the time??) slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-4.4.7 test.php Failed loading xdebug.so: (null) Time for UPPERCASE: 733.495235443 ms Time for lowercase: 712.421655655 ms slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-5.2.2 test.php Failed loading xdebug.so: (null) Time for UPPERCASE: 623.962640762 ms Time for lowercase: 619.996070862 ms David Strauss wrote:
What happens if you change the initial "$var = true;" into "$var = TRUE;"?
Steve Rude wrote:
I ran this test just to see what would happen, and here are the results, feel free to test it yourself. According to this test, running a simple loop with one if statement 100k times, you lose about 20ms using uppercase. What is interesting, is that the same test in php5 runs 100ms faster.
slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-4.4.7 test.php Time for UPPERCASE: 723.675251007 ms
Time for lowercase: 702.354669571 ms
slantview:~ steverude$ /Applications/xampp/xamppfiles/bin/php-5.2.2 test.php Time for UPPERCASE: 622.086286545 ms
Time for lowercase: 607.203245163 ms
Another interesting stat is that we have 2383 times in a stock drupal 5.1 distribution where we use an uppercase TRUE, FALSE or NULL.
Reference:
slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r TRUE * | wc -l 629 slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r FALSE * | wc -l 511 slantview:~/Documents/workspace/drupal-5.1 steverude$ grep -r NULL * | wc -l 1243
So it does not seem that unreasonable to me that we could potentially get some performance gain by standardizing on lower case true, false and null. Preference aside (me being on the uppercase side), I believe that adding this standard to the drupal standards could potentially give us a small amount of performance increase.
I also think the issue should be documented in the coding standard and reflected in the Coder module regardless of the decision.
Here is the code for the test:
slantview:~ steverude$ cat test.php <?php
function microtime_float() { list($usec, $sec) = explode(" ", microtime()); return ((float)$usec + (float)$sec); }
$var = true;
$time_total = 0; for ($i = 0; $i < 100000; ++$i) { $time_start = microtime_float(); if ($var === TRUE) { $time_end = microtime_float(); $time_total += $time_end - $time_start; } } $time_total = $time_total * 1000; print "Time for UPPERCASE: $time_total ms\n\n";
$time_total = 0; for ($i = 0; $i < 100000; ++$i) { $time_start = microtime_float(); if ($var === true) { $time_end = microtime_float(); $time_total += $time_end - $time_start; } } $time_total = $time_total * 1000; print "Time for lowercase: $time_total ms\n\n";
Thanks,
Steve Rude
Karoly Negyesi wrote:
I do not believe that true could be faster than TRUE when php is case agnostic about its identifiers. Maybe there is time taken to lowercase TRUE ... but if you can measure lowercasing four characters in the parsing stage where only ASCII is supported, congratulations.
About commas, yes the D5 menu defintiions are ugly sometimes. Have you seen D6 :) ?
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-877 x 202
-- Steve Rude + Lead Developer *AchieveInternet* (800) 618-877 x 202 http://www.achieveinternet.com
The documented standard is to use upper case for all constants, see the Constants section at: http://drupal.org/coding-standards Maybe we should add something like "This includes pre-defined PHP constants like TRUE, FALSE, and NULL." A year ago we cleaned up these constants in core, http://drupal.org/node/72204, but since then lower case instances have crept back in.
Apparently this document is in CVS, and needs someone on d.o to run CVS update. I just made the suggested change: Index: CODING_STANDARDS.html =================================================================== RCS file: /cvs/drupal-contrib/contributions/CODING_STANDARDS.html,v retrieving revision 1.8 diff -u -p -r1.8 CODING_STANDARDS.html --- CODING_STANDARDS.html 6 Aug 2007 12:04:11 -0000 1.8 +++ CODING_STANDARDS.html 27 Aug 2007 21:29:53 -0000 @@ -1,3 +1,4 @@ +<!-- $Id$ --> <p><em>Note: The Drupal Coding Standards applies to code that is to become a part of Drupal. This document is based on the <a href="http://pear.php.net/manual/en/standards.php">PEAR Coding @@ -258,8 +259,9 @@ $this->_status <h3>Constants</h3> <p>Constants should always be all-uppercase, with underscores to - separate words. Prefix constant names with the uppercased name of - the module they are a part of.</p> + separate words. This includes pre-defined PHP constants like + TRUE, FALSE, and NULL. Prefix module-defined constant names with + the uppercased name of the module they are a part of.</p> <h3>Global Variables</h3> On 8/27/07, Nedjo Rogers <nedjo@islandnet.com> wrote:
The documented standard is to use upper case for all constants, see the Constants section at:
http://drupal.org/coding-standards
Maybe we should add something like "This includes pre-defined PHP constants like TRUE, FALSE, and NULL."
A year ago we cleaned up these constants in core, http://drupal.org/node/72204, but since then lower case instances have crept back in.
participants (12)
-
add1sun -
David Strauss -
Eric Tucker -
Gerhard Killesreiter -
Karoly Negyesi -
Ken Rickard -
Konstantin Käfer -
mark burdett -
Nedjo Rogers -
Oleg Terenchuk -
Peter Wolanin -
Steve Rude