I know the speed diff is prob negligible but i read somewhere that 1 or 0 is faster.
Just wondering if anyone has benchmark this before.

No, because this has absolutely nothing to do with performance or speed. Where did you read that 1 or 0 is faster? I would love to see how they measured it.

the person didn't measure it. he just say that 1 and 0 is faster than true vs false. which is why i'm skeptical and am posting this thread.

Are you talking about PHP or a strongly-typed language?

referring tPHP

Either way, it doesn't make a difference.

I'm with fyrestrtr on this one, it would be pretty much impossible to measure (and I doubt it would be the least bit faster as with most languages true is converted to a 1 and a false is a 0 anyways).

1 == true
0 == false
true == 1
false == 0

There isn't much more to it. They will be processed equally.

Stick with coding standards, PHP generalises with TRUE and FALSE.

Not to mention true/false can be easier to read by someone not programming savvy.

Eh, even if there is some slowness it will be by around .00000000000000000002 miliseconds.

Maybe hes thinking that because 0 and 1 are both 1 char, while true and false are 4/5 chars, it's faster.

Hah

Ok, I can tell you definitavely that 1 and 0 is faster. My theory behind this is that php is not a compiled language therefore it has to interpret true and false every time it hits it.

here is the test code

<?php
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}
//concept
$p = true + false + true + false + true * true;
echo($p . "<br />");
$ii = 100000;
$s[0] = microtime_float();
for($i = 0; $i < $ii; $i++)
{
$p = true + false + true + false + true * true;
}
$e[0] = microtime_float();

$s[1] = microtime_float();
for($i = 0; $i < $ii; $i++)
{
$p = 1 + 0 + 1 + 0 + 1 * 1;
}
$e[1] = microtime_float();


echo("first time:" . ( $e[0] - $s[0] ) . "<br />");
echo("second time:" . ( $e[1] - $s[1] ) . "<br />");
echo("Ratio 1:" . ( ( $e[0] - $s[0] ) / ( $e[1] - $s[1] ) ) . "<br />");
echo("Ratio 2:" . ( ( $e[1] - $s[1] ) / ( $e[0] - $s[0] ) ) . "<br />");

?>


Here is the result

3
first time:0.21306586265564
second time:0.040096044540405
Ratio 1:5.3138873197562
Ratio 2:0.18818615070782

This shows that using 1 and 0 is ~5x faster than using true or false.
Test this code on your own systems and php versions and you will probably have similar results (while the times may be different the ratios should be close to the same). In reality this test ran 500,000 simple math calculations, and a stored the result in a variable 100,000 times. The difference is really microscopic and you should use true and false where it makes english sense.

The difference is really microscopic and you should use true and false where it makes english sense.

The key point I think the majority of posters have been trying to make.

i guess if your script has a massive loop that iterates thousands of times it would make a difference. But even with 100,000 exicutions of the above code it still took less than a second. Seems like at about 6,000,000 exicutions on the system i tested on would save you only one second of runtime.

OK. thanks korvan. time to change my true/false to 1/0

Ok, I can tell you definitavely that 1 and 0 is faster. My theory behind this is that php is not a compiled language therefore it has to interpret true and false every time it hits it.

Interesting results. If this is caused by PHP having to interpret a script, you'd then make up the speed by using a bytecode cache (Turck mmCache, eAccelerator, etc).

A lot easier than changing code and forsaking readability...

I say forget PHP, Apache, etc... Just write the code yourself in ASM (including the server portion and everything else) and be done with it. Can't get much faster than that right? I mean we're in the land of milliseconds really mattering here..

I say forget PHP, Apache, etc... Just write the code yourself in ASM (including the server portion and everything else) and be done with it. Can't get much faster than that right? I mean we're in the land of milliseconds really mattering here..
lol, love it.

The very, very small amount of execution time difference taken for 1s and 0s in comparison to true and false isn't much to worry about unless your system is rather heavy in code and requires alot of optimisation -- even to such a low level.

look. it is not a matter of whether the difference is a lot or very little.

Return 1 or 0 is essentially the same as Return True or False.

If return 1 or 0 gives you faster results, albeit minute, why not just use it?

It's like rejecting free pennies that are falling from the sky.

It's like rejecting free pennies that are falling from the sky.
If pennies are falling from the sky I am more likely to get cover than try and catch them, I want to keep my head how it is.

Well. I'm sure there are others who would wear helmets and go around collecting these pennies.

Using 1 or 0 doesn't take any extra effort from using true or false. In fact, it takes less effort since it's single characters. So you can't compare this with using assembly language to achieve faster execution time. More speed with less effort. That's the point.

maintainable > fast in most cases

sure to the computer


$a=l($u,$p);if(l==0)r('h');


might be slightly faster than


$authenticated = login($user, $password);
if ($authenticated == false) {
relocate('home')
}


but in the later case someone reading your code will clearly see what you're doing and be able to work with your code.

maintainable > fast in most cases

sure to the computer


$a=l($u,$p);if(l==0)r('h');


might be slightly faster than


$authenticated = login($user, $password);
if ($authenticated == false) {
relocate('home')
}


but in the later case someone reading your code will clearly see what you're doing and be able to work with your code.

I'm not asking you to forsake all readability for speed.

This will do.


$authenticated = login($user, $password);
if ($authenticated == 0) {
relocate('home')
}


There. It is equally maintainable and you get your free milli milli secs boost w/o trying.

I'm not asking you to forsake all readability for speed.

This will do.


$authenticated = login($user, $password);
if ($authenticated == 0) {
relocate('home')
}


There. It is equally maintainable and you get your free milli milli secs boost w/o trying.
If you really care about your milli milli seconds this would be even faster:


if ( !( $authenticated = login($user, $password) ) )
relocate('home');

or just

$authenticated = login($user, $password);
if (!$authenticated) {
relocate('home');
}

@grabmail...
I very much agree with him and if your code is fast and readable, nothing like it.

Besides that what the comments are used for in the programming, if I have a complex statement whose execution time is much faster say few ms, then I would rather spend time adding comments to it.


Blessed.

If you really care about your milli milli seconds this would be even faster
It may even be clearer, since a comparison with false when a boolean value is expected seems a little redundant, and a comparison with 0 might lead to questions asking just what other magic values might login() return.

With the logical not, we can more easily read it as "if not authenticated, relocate to home", rather than "if authenticated is 0 (or false), relocate to home". If $authenticated is never used further down the code, we might even say "if login not successful, relocate to home":
if (!login($user, $password)) {
relocate('home');
}

But I think that in the end trying to do this sort of optimisation falls under the "pre-mature optimisation is evil" category. The bottleneck most probably wont lie in the use of true or false over 1 or 0. It is just a question of which is clearer.

Okay grabmail, I did a very scientific test for you ;)...

I setup two seperate scripts, using the same logic that Korvan posted earlier. After 1 million iterations, averaged over 30 tests of each the difference was 1.041 seconds. So there you have it. The day you write an operating system in pure PHP, you are looking at saving a second of load time over the entire project.

Now does it REALLY make sense to change code from readable to less readable to save that amount of time?

I used XDebuggers profiler features for this test... so it should be highly accurate.

Well basically he asked is it faster, the simple answer is yes

No matter by how much, it is faster. You would not notice the difference until the extent where you are doing hundreds of millions of checks even then the difference would still not be all that noteable however it still helps to save whenever possible no matter how big or small it all adds up.

-Scott

Well basically he asked is it faster, the simple answer is yes

No matter by how much, it is faster. You would not notice the difference until the extent where you are doing hundreds of millions of checks even then the difference would still not be all that noteable however it still helps to save whenever possible no matter how big or small it all adds up.

-Scott

Yes. that's the point. and you are not sacrificing readibility.

It is widely known that 1 represent true and 0 represent false.

So return 1 or 0 is as readable as return true or false.

Yes. that's the point. and you are not sacrificing readibility.

It is widely known that 1 represent true and 0 represent false.

So return 1 or 0 is as readable as return true or false.

Look, all I'm saying is that there are quite a few programmers on this board that have said it's not the most functional way of doing it. Boolean values are easier to read, especially when you use a syntax highlighting program. Since they are easier to read when you are browsing through code, you are in fact sacraficing readability.

It may be widely known, but it isn't widely practiced. So you can ignore common techniques for the purpose of saving a few thousanths of a millisecond, or stick with common practice.

It is widely known that 1 represent true and 0 represent false.
It is also widely known that 1 and 0 are integer values, and may be magic constants with hidden meaning. Of course, some might argue that it is actually 0 means false, not 0 means true. It is certain, however, that true and false are boolean values, and true means true, false means false.

It may even be clearer, since a comparison with false when a boolean value is expected seems a little redundant, and a comparison with 0 might lead to questions asking just what other magic values might login() return.

With the logical not, we can more easily read it as "if not authenticated, relocate to home", rather than "if authenticated is 0 (or false), relocate to home". If $authenticated is never used further down the code, we might even say "if login not successful, relocate to home":
if (!login($user, $password)) {
relocate('home');
}

But I think that in the end trying to do this sort of optimisation falls under the "pre-mature optimisation is evil" category. The bottleneck most probably wont lie in the use of true or false over 1 or 0. It is just a question of which is clearer.

fwiw I think this way is the most readable. When people are throwing in $authentication, I'm going to spend a couple moments looking around to see what it's for. Heck, something as important as authentication and I may spend quite a while just to make sure I'm not missing something big. With the snippet above, it takes two seconds to figure out. Go back to home unless the login succeeded. Easy.

Not directed at laserlight:
Also I find it completely ridiculous to spend any time considering whether 0/1 is faster than true/false. If you actually think about something this miniscule, I can't even imagine how many other rather pointless things you waste time on, preventing you from writing usable, worthwhile software.

It is also widely known that 1 and 0 are integer values, and may be magic constants with hidden meaning. Of course, some might argue that it is actually 0 means false, not 0 means true. It is certain, however, that true and false are boolean values, and true means true, false means false.
bleh. This comes up on every programming language's mailing list every few months. Basically it boils down to 0 and 1 represent true/false in boolean algebra, but they're nothing more than symbols, and do not have any numeric value. A boolean 0 is not similar in any way to a numeric 0, other than they look the same.

if(0) returning false is nonsensical anyway, because 0 is a valid return value for many methods.

If you really want to cut down on milliseconds, I don't think PHP is the language for you. :P Sounds like a bunch of assembly programmers trying to save clock cycles. :D

But I do have a problem with using 1 or 0 instead of true or false. Firstly, PHP has a boolean type for a reason. true and false are boolean values, 1 and 0 are not.

<?php
$a = 1;
if ($a === true)
{
echo '$a is true';
}
else
{
echo '$a is not true';
}
?>

PHP treats true and false differently. Take for example the strpos() (http://www.php.net/strpos) function. It will return 0 if the index is 0, but will return false if it cannot find the string. If you use 0 instead of false, you will think it fails when it hasn't.

Further, if you care that much about speed, you're code isn't going to be readable. You're probably not going to use OOP because it's slower than procedural. But why do so many use it? Because it's more structured and organized.

Bottom line, if you care that much about speed, don't write your projects in PHP. Use C++ or something. :) PHP was written for ease of use, not speed.

But really, I don't care if your web site loads .0001 milliseconds slower because you used true.

Just my $0.02. :)

Basically it boils down to 0 and 1 represent true/false in boolean algebra, but they're nothing more than symbols, and do not have any numeric value.
That's true. However, practical computer programming is not a mere exercise in boolean algebra. It is also an exercise in contextual clues, and in this case 0 and 1 have alternative meanings as integer literals.

That's true. However, practical computer programming is not a mere exercise in boolean algebra. It is also an exercise in contextual clues, and in this case 0 and 1 have alternative meanings as integer literals.
I hardly think 0 being treated in different contexts is practical. DG already pointed out the example that I was thinking of. It also makes very common constructs overly verbose.

Compare

$pos = strpos($str1, $str2);

if($pos !== false) {
echo $pos;
}


to


if($pos = strpos($str1, $str2)) {
echo $pos;
}


Why on earth should this ever be in the documentation?
Warning

This function may return Boolean FALSE, but may also return a non-Boolean value which evaluates to FALSE, such as 0 or "". Please read the section on Booleans for more information. Use the === operator for testing the return value of this function.

Why on earth should this ever be in the documentation?

For the exact reason I posted. If the returned index is 0, the string was found, but at index 0. If it returns boolean false, then the string was not found.[

Also, have you ever tried printing out the value false? 0 displays as 0, while false displays as an empty string. true displays as 1, though

I hardly think 0 being treated in different contexts is practical. DG already pointed out the example that I was thinking of. It also makes very common constructs overly verbose.
I dont get what you mean here, at least if it isnt to support my (and Dev Gateway's) point. If, in PHP, 0 was not convertible to false (i.e. non-boolean types are made not convertible to the boolean type), then it is reasonable to write:
if ($pos = strpos($haystack, $needle)) {
}
and be certain that even if strpos() returns 0, the conditional will not evaluate to false, and hence the more verbose:
if (($pos = strpos($haystack, $needle)) !== false) {
}
is not required.

For the exact reason I posted. If the returned index is 0, the string was found, but at index 0. If it returns boolean false, then the string was not found.[

Also, have you ever tried printing out the value false? 0 displays as 0, while false displays as an empty string. true displays as 1, though

In all my posts I've been saying it makes no sense to treat 0 as false. When I asked "why on earth should this ever be in the documentation?" I was really saying, "If you just treat 0 as a valid value (as it is in this case) and false as false, there would be no reason to have warnings sprinkled throughout the documentation."

Basically when I see documentation like that, I interpret it as a deficiency of the language. Maybe not everyone believes code should be instantly readable though *shrug*

I dont get what you mean here, at least if it isnt to support my (and Dev Gateway's) point. If, in PHP, 0 was not convertible to false (i.e. non-boolean types are made not convertible to the boolean type), then it is reasonable to write:
if ($pos = strpos($haystack, $needle)) {
}
and be certain that even if strpos() returns 0, the conditional will not evaluate to false, and hence the more verbose:
if (($pos = strpos($haystack, $needle)) !== false) {
}
is not required.

As far as I can tell, DG and I are on one side of the argument, and you're on the other.

Example:

$haystack = 'foobar'
$needle = 'foo'

if($pos = strpos($haystack, $needle)) {
echo $pos;
}


Because PHP treats 0 as false, the conditional will evaluate to false, even though it's obviously true.

In all my posts I've been saying it makes no sense to treat 0 as false. When I asked "why on earth should this ever be in the documentation?" I was really saying, "If you just treat 0 as a valid value (as it is in this case) and false as false, there would be no reason to have warnings sprinkled throughout the documentation."
Oh, okay, that clarifies your point. Sorry for the misinterpretation.

I can see where you are coming from, but then PHP does have some legacy in C, which only recently (C99, I think) introduced a native boolean type... and even then integer types remain convertible to _Bool.

As far as I can tell, DG and I are on one side of the argument, and you're on the other.
My point is exactly what Dev Gateway wrote:
PHP has a boolean type for a reason. true and false are boolean values, 1 and 0 are not.
Though on a technicality although 1 and 0 are not boolean values, they are convertible to boolean values. This is precisely where the problem we discuss pertaining to strpos() returning 0 or false lies.

In all my posts I've been saying it makes no sense to treat 0 as false. When I asked "why on earth should this ever be in the documentation?" I was really saying, "If you just treat 0 as a valid value (as it is in this case) and false as false, there would be no reason to have warnings sprinkled throughout the documentation."

Basically when I see documentation like that, I interpret it as a deficiency of the language. Maybe not everyone believes code should be instantly readable though *shrug*

ah, I misread your post.

I agree with you then. However, in many languages false is equal to 0. For instance, in C++, I believe false is defined as:

#define false 0

So people may have a reason to believe they are indeed the same.

For instance, in C++, I believe false is defined as:

#define false 0
It might be for some implementations, but then the C++ Standard only mandates that values of type bool be either true or false, and that there are conversions between other types to boolean true/false.

I might be thinking of the Windows API, I know for a fact that is

#define TRUE 1
#define FALSE 0

Since that is widely used in both C and C++, and there is no true/false in C.

I'm surprised this thread became this long. :)

The reason that 1 and 0 is faster (extremely slightly) than true or false is that the compiler/interpreter must take one extra step to convert true to 1, and false to 0.

Similarly, when you compare a string to another string, the compiler is not comparing whether a letter matches a letter, it really is comparing the ASCII value (integer) of a letter. Comparisons are done in integers.

So does this mean that you should use ASCII values when comparing strings? No, use what makes development/maintenance time easier for you.

Ah, wrong again. For languages with defined boolean types, there is no conversion between the integer 1 and true and the integer 0 and false. They are two different types.

0 does not mean 'false'. 0 is a number (integer). 'false' or FALSE is a boolean type. It is there to express a truth value. None of which can be expressed by 1 or 0.

What I mean is, the boolean data type is eventually converted to a 1 or 0. A boolean is just a a bit that is on or off.

Like C or C++ for example, would have this code in the header or standard library.
#define FALSE 0
#define TRUE 1

to create defined boolean types, which just says, define FALSE as the integer 0, and TRUE as the integer 1. A compiler converts source code to machine language, which are just 0's and 1's.

In C programming language, a char is its own defined data type, but all it really is is an integer that holds the ASCII value of the character. The same with boolean in this case. In the end, it's just a comparison of integers.