Javascript run-time analysis

I've written a Javascript file, using jQuery, that I would like to perform run-time tests on. I've never done this before and was just curious on how to go about it. One site I visited suggested this as a measurement:

var start = (new Date).getTime();
/* Run a test. */
v开发者_JAVA技巧ar diff = (new Date).getTime() - start;

This makes sense, right now my script is acting on a web page, all it does is sort clicked-on columns in a table. What I'm interested in knowing, besides the actual timings, is how to interpret the timings in Big-O notation. Also, is this the most standard method of measuring script run-times? Your thoughts are appreciated.

UPDATE: Thanks guys for your input, installed Firebug and am playing with the profiler. I'll attempt to see if I can come up with an approximation to check the timings against for Big-O notation.

Install firefox with firebug, then add console.time('anyTimerYouWant'); to start the timer and console.timeEnd('anyTimerYouWant'); to end it.

BigO notation cannot be easily programmatically calculated as far as I know.

The Firefox Firebug tool can be used to profile javascript and function execution time. You can find out more at http://getfirebug.com/js.html

As far as interpreting timings "in Big-O notation", what you'd need to do is take a series of timings for different size inputs and then find a correlation between the resulting times and some approximation. If the approximation that fits best is linear, then it's probably O(n), if it's logarithmic, O(log(n)), if it's a 2nd-order polynomial, O(n^2), et cetera.

I believe getting the start end time is the most standard way of measuring script run times. Generally speaking, you can figure out big O without using a timer, but just by looking at your code. Keep in mind, though, that with JavaScript, the biggest bottlenecks might not be the actual code, but the time it takes for the browser to update the page (if for instance you're constantly changing the DOM in your sort algorithm). It's quicker to make DOM changes all at once, rather than little by little.

Can you try this? It's a method that doesn't measure, it just tells what's costing the most time, as well as giving a good idea of what's happening time-wise.

I'm not sure what the purpose of your code is but I would not try to infer big O notion analysis from actually timing the code. The whole idea of big O notion is the the asymptotic number of steps as a factor of n, your input. Sorting algorithms are bigger or equal to O(n*log(n)), so it can't be O(n). BTW, when numbers are not big enough it is very hard to tell O(n) from O(n*log(n)).