Reposting this from IRC since it's pretty complex:

Here's my predicament:

I am doing JIT sound buffering with a JavaScriptNode in the AudioContext API. The way it works is that the AudioContext gives me an input buffer (which I'm not concerned with), and output buffer, and a time range. In order to populate the output buffer, I have to do some computationally intensive stuff that involves several hundred to several thousand iterations over another array. Doing that requires a lot of variables.

Currently I have all those 'temp' variables declared globally. My thinking was that by doing that, I won't have to reallocate space every time the function gets called for these variables so I should get a performance boost. However I just did some reading and discovered there is a performance hit in Chrome (only browser this app is supported for) for resolving global variables.

So my question is - am I going to take a bigger hit on global variable resolution than local variable allocation? It's kind of difficult to test this given that there are a lot of variables that can affect the performance and the fact that it's hard to repro the event object that gets passed to the function, so general pointers before I get deep into testing (which I'd rather not spend a ton of time on) would be appreciated. Cheers and thanks for the help guys!

Edit: After looking at some of the comments on the post I linked to, Chrome seems like it may have resolved the global variable identifier resolution issue after the post was written. It's probably a safe bet that globals are gonna be better in this situation but I'd love to hear your opinions.

Edit 2: One possible solution that just occurred to me is to put the variables I need to access in the buffering function in a closure so they resolve quicker within scope but do not need to be reallocated...

Edit 3: One additional question for those familiar with HTML5 Canvas: How likely would setting a background-image on the canvas be to affect performance assuming I will be animating frames at roughly similar intervals as the function described above?

Edit 4: After doing some (admittedly subjective) testing, using a closure seems like it might be ever so slightly faster. Whatever the case, it doesn't seem to make a huge difference. Although the current performance I'm getting is _acceptable_, it could still stand to improve. I was hoping to avoid this, but I think I am going to look into adding and additional node to serve as a cache which will bypass my computationally intensive function if the data it uses hasn't changed.

1) Write clean code first - then worry about performance. I wouldn't worry at all about the global/local performance, put the variables where they belong, performance difference will likely be immeasurable. Although with that said, the further out in scope, typically the slower it will be. Locals are the fastest to access afaik.

2) Chrome has a JS profiler, use it.

3) If you will be clearing the canvas every frame, put the background in the canvas and draw that image instead of doing a clear. If you will be drawing over and over on top of it, it doesn't matter if it's in the canvas or not.

Believe me I'm all about writing clean code first and optimizing later, but the nature of this app dictates that performance must be given top priority from the beginning. The audio signal produced changes drastically based on how quickly I buffer because the AudioContext will play whatever signal has been buffered at a given point in time regardless of whether my computation has finished, so speed is vital.


Ooh, good tip, I don't know why I didn't think of that. I'll report back with results if I have time.


I will not be clearing the canvas every frame so it sounds like my background image will be just fine. Based on some brief testing I didn't notice any performance hit from including it.

Thanks for your feedback dude.