17

During a code review I was told that
if(x and y){
if(z){}
}

Will be slower to run than
if(x and y and z){}

I mean if you want to talk about programming practices and uniform code yes absolutely but any compiler will treat these identically, not to mention the assembly being identical. She was a superior though so I just went along with it.

Comments
  • 2
    How’s the first one is slower than the second one?
  • 4
    @freeme it absolutely isn't, that was why I had to rant about the code review
  • 1
    @FrodoSwaggins I jumped to stack overflow after the review and everything I saw said it was just a readability question, never considered that it may load an extra jump though, really glad for that input. I totally missed that.
  • 1
    @FrodoSwaggins I need to start running tests when something like this comes up, thanks for reporting back, I would have really never guessed. Did you use a compiled or interpreted language?
  • 1
    @FrodoSwaggins I have a fair amount of knowledge about assembly, but not about optimization. I would have thought every evaluation in an if bracket generates an individual jump (so it either jumps to the next evaluation or behind the if). If I'm thinking correctly, nested if's would have zero impact then. Could you explain where I'm wrong? Only idea I currently have is that all evaluations that are combined by 'and' are summed together and checked for a true/zero value ('jz') in the end.
  • 0
    @FrodoSwaggins thank you for all the details, never knew that at least I now know what O3 is for, I used to use when compiling Android kernel but didn't really understand why it is better
    Wish I can subscribe to user comments :/
  • 0
    @FrodoSwaggins I see, I do recall seeing improvements in the kernel using O3, I wouldn't consider my self as developing it as I was just applying patches from the linux kernel and adding few cpu governors & IO Schedules + playing around in its config. Though why are Linux binaries using O1? is it due to backward compatibility?
  • 0
    Technically they are right.
    Since most languages implement "and" in such a way that once a "false" is determined it stops evaulating further.

    So like if "a" is false the program stops at "a"
    So like if "b" is false the program stops at "a and b"
    So like if "c" is false the program stops at "a and b and c"

    And so on
  • 0
    @FrodoSwaggins Did you test how much the frame rate could be increased by using O2?
  • 0
    @FrodoSwaggins I see, thanks for the info man really appreciate it :)
Add Comment