views:

2391

answers:

10

CPU Cycles, Memory Usage, Execution Time, etc.?

Added: Is there a quantitative way of testing performance in JavaScript besides just perception of how fast the code runs?

A: 

Chrome has some good tools built in for this.

Kevin Conner
A: 

The golden rule is to NOT under ANY circumstances lock your users browser. After that, I usually look at execution time, followed by memory usage (unless you're doing something crazy, in which case it could be a higher priority).

William Keller
+1  A: 

I find execution time to be the best measure.

pdavis
As opposed to what? I'm not sure I understand.
Pekka
As opposed to the orignal posters question: "CPU Cycles, Memory Usage, Execution Time, etc.?"
snicker
+1  A: 

You might like to look at the YSlow plugin for Firefox.

Rob Wells
That's only going to tell you how long it takes to load. I think the question was more concerned with performance when it is running.
Sam Hasler
+3  A: 

You could use this: http://getfirebug.com/js.html. It has a profiler for JavaScript.

John Boker
+5  A: 

Some people are suggesting specific plug-ins and/or browsers. I would not because they're only really useful for that one platform; a test run on Firefox will not translate accurately to IE7. Considering 99.999999% of sites have more than one browser visit them, you need to check performance on all the popular platforms.

My suggestion would be to keep this in the JS. Create a benchmarking page with all your JS test on and time the execution. You could even have it AJAX-post the results back to you to keep it fully automated.

Then just rinse and repeat over different platforms.

Oli
this is true, but profilers are good in case there is a coding problem that has nothing to do with a browser specific issue.
John Boker
Sure! Yeah they'll catch general "bad coding" problems and specific ones are great for doing the actual debugging, but for general use-case testing, you'll benefit from something that runs on all platforms.
Oli
+1 on the note that this is true, but having a profiler like Firebug is still great, if not essential, to find bottlenecks.
Pekka
+4  A: 

Profilers are definitely a good way to get numbers, but in my experience, perceived performance is all that matters to the user/client. For example, we had a project with an Ext accordion that expanded to show some data and then a few nested Ext grids. Everything was actually rendering pretty fast, no single operation took a long time, there was just a lot of information being rendered all at once, so it felt slow to the user.

We 'fixed' this, not by switching to a faster component, or optimizing some method, but by rendering the data first, then rendering the grids with a setTimeout. So, the information appeared first, then the grids would pop into place a second later. Overall, it took slightly more processing time to do it that way, but to the user, the perceived performance was improved.

noah
yes yes yes. I wish I could mod you up 2x ++1
Byron Whitlock
+2  A: 

I think JavaScript performance (time) testing is quite enough. I found a very handy article about JavaScript performance testing here.

jQuery Lover
A: 

I usually just test javascript performance, how long script runs. jQuery Lover gave a good article link for testing javascript code performance, but the article only shows how to test how long your javascript code runs. I would also recommend reading article called "5 tips on improving your jQuery code while working with huge data sets".

Uzbekjon
A: 

We can always measure time taken by any function by simple date object.

var start = +new Date();  // log start timestamp
function1();
var end =  +new Date();  // log end timestamp
var diff = end - start;
pramodc84