Is is faster to just.... not check some condition?

Newbie & Debugging Questions
#1

Here’s a stupid scenario to illustrate a problem
Let’s say that sometimes some boolean variable “condition” is true
Now, we have some object, and one of this object’s “jobs” is to make condition false is condition is ever true.

Is there a point to doing

if(condition){
     condition = false;
}

or is simply doing

condition = false;

faster? (does it change, depending on about how often “condition” is true?)

Does looking up the state of a variable take less time than simply setting it?
This is just a miniscule efficiency problem that i’ve always wondered about.

RELATED: do certain “lookups” take longer than others? Like, does checking a boolean take less time than checking an int, and does that take less time than checking if an object is some subclass? By how much?

Thanks!

#2

80% sure, both will have the same performance.
Actually

condition = false

is faster. But since our nice JVM optimizes code, it optimizes

 if (condition) condition = false;

to the above. You could simply think of the lookup being about as fast as the “set”.

#3

Checking and changing 1 bit of data? Im pretty sure it is so insignificant and fast that it turns out to be unmesurable

Also, you can do it using ternary, but it is more confusing and you can’t omit the second statement :confused:

condition = condition ? !condition : condition;
#4

Booleans are not represented by one bit by the JVM - if I recall correctly a boolean value might take up to 4 bytes of memory. I think checking for true and then setting to false cannot ever be faster - you have to read the value, make a comparison then write the value. I think there might be something wrong with the flow if you are setting the field a zillion times…

#5

I think in Java booleans can even be as big as 32byte.

But nevertheless

This should be true. Like measuring the weight of one or ten electrons =D

#6

Are we talking about the same boolean here? Do you actually mean the java.lang.Boolean (which of course can get 32 bytes big… all the JVM overhead :open_mouth: ) or are we talking about the generic-type-boolean, which (I’m pretty sure) takes 1 byte ?

#7

Well, this guy claims 32 bits (not bytes), which would match my 4 byte claim:

http://weblogs.java.net/blog/dwalend/archive/2007/11/the_thing_about.html

#8

Good find!
And now i also know that using an array of booleans is less efficient than using N booleans

#9

Nope… Looks like booleans inside the STACK are 32 bits of data. But inside Arrays and classes they only take 8 bits (as I expected). That is rather “normal”, because C and some other languages also use 8 bits per boolean. In C++ there is the nice vector class, which has a implementation of boolean arrays taking only 1 bit per boolean. Access and writing is a bit slower, but I think thats quite okey for 8x less data :wink:

#10

Well, my point was that it wasn’t one bit… “one to four bytes” would be the accurate statement I guess. You can always make your own bitmask if it really matters.

#11

That’s a rather roundabout way of saying:

condition = false;
#12

This “optimization” is so evil that just looking at it makes me sin.

#13

But it is near optimal. Assuming writing obtuse code is the goal.

#14

The entire line looks dumb either way
It is called brute force, when you don’t want to lose time debugging, so you just maul a value on the variable (Don’t do this at home!):

if (var == 40) {
    doSomething(var);
}
else {
    var = 40;
    doSomething(var);
}

It is on the same class as the fair dice roll

#15

That doesn’t work either: transformed into the else statement in the same way as loosing the original if of OP.

#16

ah yes I meant 32bits