I'm working on a javascript application that makes intensive use of math operations, dozens of calls per mouse move. I've been working on others' people code as a starting point, and I often find work arounds for the native javascript Math, such as...

var pi = Math.PI
var distance = (x * x) + (y * y) / R * R
var pixels = ~~(x/y)

Is there a significant performance hit for using the Math object? If so, what are some common workarounds?

I'm working on a javascript application that makes intensive use of math operations, dozens of calls per mouse move. I've been working on others' people code as a starting point, and I often find work arounds for the native javascript Math, such as...

var pi = Math.PI
var distance = (x * x) + (y * y) / R * R
var pixels = ~~(x/y)

Is there a significant performance hit for using the Math object? If so, what are some common workarounds?

• javascript

• 1 Probably the Math methods are implemented in the language that javascript is implemented in (i.e. C or C++ in a typical browser) so they are much faster than what you can write in Javascript – Seth Carnegie Commented Jan 16, 2012 at 19:38
• 5 Have you measured the difference in performance? Across all your target browsers? – Greg Hewgill Commented Jan 16, 2012 at 19:39
• 2 Well Math doesn't have a "distance" method, and that integer conversion might be faster but it's also semantically different than Math.floor() or Math.round(). You can use [jsperf](jsperf.com) to test this sort of thing. – Pointy Commented Jan 16, 2012 at 19:39
• Are you experiencing performance problems or is this a case of premature optimization? Assuming the former have you done any profiling? – Jordan Running Commented Jan 16, 2012 at 19:41
• @SethCarnegie: Sure, if you're interpreting them. But any performance-sensitive JS will be compiled now, so x*x and Math.pow(x, 2) will be almost identical in terms of code-generated. – gsnedders Commented Jan 16, 2012 at 20:00

2 Answers 2

If you are for some reason doing computing intensive stuff in javascript, you must remember those things (*and read David Mandelin's Know Your Engines: How to Make Your JavaScript Fast presentation - PDF, where he describes this in more details*):

1. inline everything you can.

2. function calls are very expensive

3. object access is expensive

4. polymorphism can cost you performance, your variables and arguments should always hold only one data type.

Math object is not especially slow, but you will not find distance() function there anyway, and accessing its methods from closure via Math.method() calls is, inefficient.

so sqrt is, of course, worse than x*x, custom random function might be better for you, Pi should be cached in loops, min and max should probably be avoided as well, no idea about trigonometry and logarithms speed.

P.S.: You can do things like ((x >= 0 ? x : -x) + 0.5) >> 0, to replace Math.ceil(Math.abs()), but remember - when i say "intensive" - i'm talking about number crunching, data processing, physics, graphics and things like that. For normal JavaScript sites or RIAs - you should not do stuff i am suggesting here. Also, most of the speed hacks have their side effects

I do not agree on the function calls. if statements inside if statements and long specialised functions is slower than well organised code with many small generalised functions.