Recommended Posts

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..."

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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

Share this post


Link to post
Share on other sites

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..."

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this