Which one is faster:- Max, Min or ?:

Currently there are few cases which needs variables to be set at max of two numbers or min of two numbers. I didnt want to go through if else loops to set the variables. So I set them up with ?: for eg.

maxx = this.x > player.x?this.x:player.x;

This works fine. But just now I thought I could also use Math.max or Math.min for the same. But I dunno which function is faster. Or is there any difference at all.

“if/else” is not a loop

As Math.max() is a static function call, it is probably slower than the ternary conditional operator.
Just run a test yourself, if you need an exact answer.

I doubt that this will effect the execution speed of your code in any drastic way.

Oh lol. Didnt mean to call them loops. Just too many conditionals…

Well they say save now to reap later (Or something), I am just trying to code efficiently and hopefully in long run this will benefit me.

Aren’t static function calls faster than normal function calls?

Don’t code with optimization in mind.

Originally posted by NineFiveThree:

Don’t code with optimization in mind.

Agreed.

Focus on making your code as easy to read as possible. It will benefit you in the long run.

function calls are always slower than conditionals; conditionals are short jumps, function calls are long jumps.

also, due to quirks of the compiler

if (thix.x > player.x) {
    maxx = this.x;
} else {
    maxx = player.x;
}

is faster than the ternary operator. however, this is liable to change in a later version of the compilers, so do not hold it to be absolute fact, and instead hold it to be a temporary but insignificant bug.

Wow. Something new to learn. Thanks for the replies. Oh yeah now I think of it function usually produce overhead, silly of me to think function can be faster than a conditional.

Don’t code with optimization in mind.

Ignore this advice as if it were the Devil speaking to you. Seriously, I don’t even know what to say to this.

Don’t listen to truefire, use as much AS2 and timeline coding that you possibly can. Also leave your under-cooked food unrefrigerated for days before you eat it.

More seriously, the “don’t optimize too early” mantra has gone too far. It was supposed to be a statement about how you shouldn’t make your code unreadable early on for speed gains (for obvious reasons), but now people seem to think that optimizing itself is a bad act.

Do optimize. You will learn a great deal and become a better developer because of it. Don’t listen to the naysayers.

Oh man, I was totally wrong. You have shown me the light Drakim! I think I still have some rancid cottage cheese, so I should be OK food-wise!

Seriously, unless speed is absolutely critical, and I do mean critical to the application, clarity trumps speed any day of the week. Why would you want to sacrifice clarity so your code can nap a little bit longer between frames? Dirty code is a much greater danger to a project than slow code. I’d go even further: For all the horror stories about spaghetti code and inextricable legacy messes that had to be thrown away and rewritten from scratch because nobody had any clue how they worked or why they didn’t, I have never heard anyone say: “But then we had to scrap the project because the program was running slower than we expected.” You want to optimize your code? Clean it up. Clear code is optimal code.

This is the logic that Math.min uses when only two arguments are passed:

x < y || isNaN(x) ? x : y

Unsurprisingly, it’s similar to your logic.

Originally posted by Ace_Blue:

Seriously, unless speed is absolutely critical, and I do mean critical to the application, clarity trumps speed any day of the week. Why would you want to sacrifice clarity so your code can nap a little bit longer between frames? Dirty code is a much greater danger to a project than slow code. I’d go even further: For all the horror stories about spaghetti code and inextricable legacy messes that had to be thrown away and rewritten from scratch because nobody had any clue how they worked or why they didn’t, I have never heard anyone say: “But then we had to scrap the project because the program was running slower than we expected.” You want to optimize your code? Clean it up. Clear code is optimal code.

As I was saying, one shouldn’t make the code unreadable early on for speed gains, but it is possible to disregard performance too much. Flash developers are notorious for this, and it has given the flash plugin a reputation of being bloated and slow (when in fact it’s pretty decent these days).

While it’s entirely possible to make a trivial game without having to care much for speed, the second you want anything of substance, like a huge Castlevania style map, cool dynamic shadows, or hundreds of zerglings at the same time, you need to start taking performance into account.

It is not okay to require that the player has a modern gaming rig to run your little 2d flash game. If you do that your game will be scored low and your reputation as a game developer will be rated at the same level as the pop music artists who cannot play any instruments and has to have auto-tuning to have a tolerable singing voice.

If skyboy wasn’t clear, The ternary is faster (Though an if is better, marginally).

Function call overhead is big in flash, and Math.min is no exception. (I really wish Adobe would support in-lining of some of their native functions).

I understand what you’re saying Drakim, my problem is that I’m reading this:

While it’s entirely possible to make a trivial game without having to care much for speed, the second you want anything of substance […] you need to start taking performance into account.

next to this:

Aren’t static function calls faster than normal function calls?

and this:

[If then else] is faster than the ternary operator.

and this:

Function call overhead is big in flash

Seriously, someone who is that hard-up for squeezing the last little drop of performance out of their code better first make sure the rest of it is damn tight. Frankly, unless you’re already trying to do a lot more than you should be doing every frame none of these “tricks” is going to make a iota of difference. Piling everything you do in a single function of a single class because you’re afraid to make function calls will turn your code into a horrendous mess, though.

It shouldn’t be necessary for Math.min to check if the argument sent is NaN… Nothing is ever supposed to be NaN and if it ever was, it shouldn’t pass through the function like that… imo.

@Ace_Blue: When you’re working with an absurd amount of bullets/enemies/misc particles @ 60fps, you really can’t afford to not code with performance & speed optimizations in mind—especially if you are foolish like me and are doing so in AS2.

Let’s just compromise with: “Optimize your code for readability, but make sure you’re doing so with an awareness of what is fast vs what is slow.”

Frankly, unless you’re already trying to do a lot more than you should be doing every frame none of these “tricks” is going to make a iota of difference.

>>Function call overhead is big in flash

This is not a little “trick”. Understanding this is INTEGRAL to making any low level stuff in flash. If you’re designing a rendering system, and you think you can use setPixel freely, you are in for an unpleasant surprise.

Furthermore, you are making the mistake of measuring performance in ‘absolute’ values. “function call overhead is only half a nanosecond, that’s not much”. Performances can only be properly measured in relative amounts. “100x faster” is an excellent performance gain. Even if it’s only .5ns vs .005ns. If you’re doing it a billion times, that’s the difference between half a second, and .005 seconds.

Aren’t static function calls faster than normal function calls?

AFAIK, Adobe fixed this.

Originally posted by truefire:

Ignore this advice as if it were the Devil speaking to you.

Why?

Originally posted by NineFiveThree:

Originally posted by truefire:

Ignore this advice as if it were the Devil speaking to you.

Why?

read on :)

I think what they mean is DO worry about optimizing but not to the point where it goes the fastest it can. Find a compromise where it’s readable and fast, and in the end when you’re almost done focus on optimizing. It should be a polishing thing but not only for polishing.

Originally posted by BigJM:

This is the logic that Math.min uses when only two arguments are passed:

x < y || isNaN(x) ? x : y

Unsurprisingly, it’s similar to your logic.

honestly, most of the time there is no worry about NaN. and in virtually all use-cases, NaN is the less desirable value, even if it is technically smaller and larger than every other value.

Originally posted by truefire:

If skyboy wasn’t clear, The ternary is faster (Though an if is better, marginally).

Function call overhead is big in flash, and Math.min is no exception. (I really wish Adobe would support in-lining of some of their native functions).

they do. selectively. isNaN is inlined such that it is equal in speed to x !== x however, x === x is still a faster comparison than !isNaN due to the avoidance of the double-not issue.

Originally posted by Ace_Blue:

Seriously, someone who is that hard-up for squeezing the last little drop of performance out of their code better first make sure the rest of it is damn tight. Frankly, unless you’re already trying to do a lot more than you should be doing every frame none of these “tricks” is going to make a iota of difference. Piling everything you do in a single function of a single class because you’re afraid to make function calls will turn your code into a horrendous mess, though.

the problem is – are you trying to do more per frame than what you should be doing on an older computer? they exist, and when you target flash, you need to target the lowest common denominator; so if you want a 3D game, target computers as fast as the xbox (not 360) or PS3, best is if you can get a sliding scale of effects such that you can target both levels.
however, you want a 2D game? please, please, please don’t use the molehill APIs. just as with terarria, there’s no reason that the lowest settings on your game shouldn’t be able to run on a computer 10 years old (particularly since 2.7 GHz CPUs were in mid-grade consumer computers). if you want a lot of fancy effects – sure, go for it. but include the option to turn every last one of them off, or swap their quality to a very low setting.

as for function calls: doing everything in one function is hugely slower than having multiple functions in almost all cases (ignoring iterative/recursive things). having all registers freed up for a new function can, in most cases, be of greater benefit to speed than not making the function call in the first place.

Originally posted by NineFiveThree:

Originally posted by truefire:

Ignore this advice as if it were the Devil speaking to you.

Why?

ignoring performance completely is far, far worse than optimizing too much too soon. at the end you either have a painfully slow implementation, or you have to do twice as much work just to get down to a level of performance if you’d started coding with performance in mind. save yourself the effort, be performance aware, so you can make better design choices, such that doing hard optimization is less work.

I was just posting Adobe’s implementation for interest’s sake…

Originally posted by BigJM:

I was just posting Adobe’s implementation for interest’s sake…

Adobe’s implementation is controlled by ECMAScript’s documentation, which doesn’t always make sense: x/0 is Infinity for all positive x, -Infinity for all negative x, and NaN for all 0 x (there are two! -0 and +0) but in real math, anything divided by 0 is undefined

Awesome stuff this. I always like constructive fights.
Anyways I wanted to share how I work. I usually take on a function or a class at a time. Finish it completely, stress test if its works as it should. Then go about optimizing it to its fullest extend. Stress test again. Repeat if some bugs otherwise once a function or class is made it can be later used in code anywhere with a simple line. :) I dont usually even look at the code of class which is already finished. Maybe one last time after everything is coded or if something has to be changed behavior-wise.