JS Optimization

After profiling, I see that roughly 25-30% of my program's time is spent inside this function.

Unfortunately, this isn't my algorithm, and I don't think I can improve it. The paper it came from is here: http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/GDC03.pdf

My only option seems to be "performance tricks", but I don't see any openings. The only thing I can say for sure that I haven't tried is ``loop unrolling'', but I don't have much experience doing that myself, and I don't see how I could do it here while staying in bounds. If it helps, height, width, and iterations are all set by the user.

So: any ideas on how to improve the performance of this code?

function lin_solve(b, x, x0, a, c) {
        if (a === 0 && c === 1) {
            for (var j = 1; j <= height; j++) {
                var currentRow = j * rowSize;
                ++currentRow;
        var i = width - 1; do {
                    x[currentRow] = x0[currentRow];
                    ++currentRow;
                } while (i--);
            }
            set_bnd(b, x);
        } else {
            var invC = 1 / c;
            for (var k = 0; k < iterations; k++) {
                for (var j = 1; j <= height; j++) {
                    var lastRow = (j - 1) * rowSize;
                    var currentRow = j * rowSize;
                    var nextRow = (j + 1) * rowSize;
                    var lastX = x[currentRow];
                    ++currentRow;
                   
            var i = width; do {
                        lastX = x[currentRow] = (x0[currentRow] + a*(lastX+x[++currentRow]+x[++lastRow]+x[++nextRow])) * invC;
            } while (i-- > 1)
                }
                set_bnd(b, x);
            }
        }
    }

>>11
This is what I would do, but frankly, I'm not that talented. This is "Babby's first fluid dynamics" for me.

>>12
As of right now, most of it isn't actually the Javascript, kind of.

~60% of it is spent by the browser, natively, in its DOM rendering procedure.

This is a bottleneck correlates with my program. I've written an ASCII renderer for the fluid solver, and the display function is essentially an Array.join and a call to innerHTML. I imagine browsers don't optimize for redrawing a big-ass text block once every 10 ms.

I might be able to have more faster speeds with a canvas made to look like any old element, scaled to the page dimensions, or maybe some SVG trickery.

(This feedback from the profiler is a bit confusing, because it says that the call to innerHTML accounts for less than 1%. However, I'm pretty sure that's what's going on.)

~7% of it is spent in the garbage collector.

My guess is that the advantages from temporary cache values outweigh the extra time spent collecting. I would try optimizing for this as a very last resort.

~30% is spent on the physics solver's update function.

I've managed to take down the lin_solve time to ~12-15% by lowering the iterations and doing half of what >>11 suggested (I'm currently working on how to unroll the second, more complicated set of loops -- we'll see if it helps at all).

~7% is a different solver function, advect, and another ~6% is in project. Each have nested width/height loops with multiplications, so I might be able to do some unrolling as per >>11's advice.

Ha. Aren't you glad you asked?