More is better?

[phjvh 0]

Hi,In my quest for more efficient code, with as goal better FPS, which code is faster? (Got a lot of them!!) (L:condition,number) 100 < if{ (L:failure 1,bool) ! if{ 1 (>L:failure 1,bool) } (L:failure 2,bool) ! if{ 1 (>L:failure 2,bool) } etc. } els{ (L:failure 1,bool) if{ 0 (>L:failure 1,bool) } (L:failure 2,bool) if{ 0 (>L:failure 2,bool) } etc. } or(L:condition,number) 100 < if{ 1 (>L:failure 1,bool) 1 (>L:failure 2,bool) etc. } els{ 0 (>L:failure 1,bool) 0 (>L:failure 2,bool) etc. } Jan"Beatus ille qui procul negotiis..."

[rcbarend 37]

Hi Jan,IMO the second construction would allways be more efficient, because, depending the actual valuea of the bool's, in the first construction either more stackoperations are needed or (in the final CPU code) a JMP instruction is executed.But for such simple code, you would 100.000+ (or more ?) of code lines to ever see an FPS difference.Moreover, construction-2 is simpler :-)I would only use Construction-1 when the code was generating FS9 events instead of setting variables. To prevent inducing the "continuous event" problem (which Construction-2 would do).Cheers, Rob

[phjvh 0]

Thanks Rob,Now I shall continue with the "simple" ones.The "Events Firing problem" is history thanks to Doug.Jan"Beatus ille qui procul negotiis..."

[taguilo 33]

Jan,This "third option" should be the most efficient:(L:condition,number) 100 < d (>L:failure 1,bool) (>L:failure 2,bool) etcproviding failure lvars must accept the same logical value of the first comparison (which may not be the case usually).Tom

[rcbarend 37]

Hi Tom,Yes, as far as run-time efficiency is concerned: of course you are right!But I personally try to avoid constructions like that (i.e. do a test without it being followed by an IF contruction) because I find it makes the code less readable/understandable, and therefore less maintainable. Besides, it only works for booleans, not generic numbers.But I guess that's a matter of personal taste :-)And optimising for maintainability instead of efficiency is something I try to do for years now, because it happened too often to me, that, when I was adapting/extending a piece of tricky, but efficient code, I made stupid mistakes :-)Cheers, Rob