HN Explorer

HTML5 Canvas performance: low-level optimization tips and tricks (elekslabs.com)

35 points by victor_haydin ↗ HN
Low-level optimizations matter even if you write your code in high-level language such as JavaScript. Code is still executed on same hardware as if you write it on C++. Each JavaScript engine is different. You can have significant performance boost in one browser, but at the same time your fix may make your code slower in another browser. Test your code in all browsers your application must work with. Keep the balance between code readability and performance considerations. Sometimes it makes sense to inline function even if it makes your code less readable. But always make sure that it brings you desired value: it doesn’t make sense to sacrifice code readability for 2 ms performance boost for code that is already fast enough. Think about object allocation, memory usage and cache utilization, especially if you work with memory intensive algorithms.

5 comments

[ 4.0 ms ] story [ 26.1 ms ] thread
binarymax
Kudos, writing flood fill is tricky...lots of gotchas. Another tip: always use === instead of == if you are doing numeric compares. You might see a perf increase there.

If you are interested, I have a decently quick floodfill here. Might be worth a benchmark but never got around to it: https://gist.github.com/4071852

Another thing is, this stuff can easily be thrown into a webworker, which will definitely help with some more complicated fills on larger canvases.

gbenitez
Also creating dictionaries (associative arrays) may help to keep track of objects without having to run over the whole array every time you need to access an object.
kevingadd
This is only true if you're doing a ton of array searching. Using an Object as a dictionary in JS has a lot of overhead so it's going to be much slower than using a dense array in many cases.
kevingadd
Function inlining is absolutely automatic in modern JS runtimes. Of course, that doesn't mean the functions you want inlined will get inlined, so it can still occasionally pay off to do it by hand - but make sure you test to see if the results are actually better. Sometimes the runtime will decide not to inline a function for a good reason. For example, if the function you're calling has something wrong with it that deoptimizes it in the JS runtime, inlining that function will successfully deoptimize the outer function. Now more of your code is running slowly.

EDIT: If you're micro-optimizing, why not cache '((hitColor >> 24) & 0xFF)' in a local at the top of the function instead of computing it every iteration? Loop invariant code motion might hoist it for you, but I don't know why you wouldn't do that by hand.

Also, wrapping your integer arithmetic in ( ) | 0 may improve its performance in Firefox and some other browsers because it allows the JIT to omit overflow checks. Should help since you're doing a lot of addition to index into arrays.

leeoniya
nice article. i've been optimizing my canvas algos for the last couple days and i'll see what other bits i can pull from here. keep in mind, firefox may take a nose dive in canvas ImageData performance (we-re talking a factor of 2-3) if this bug isnt resolved soon - https://bugzilla.mozilla.org/show_bug.cgi?id=746773.

my nightly FF does in 500ms what FF16 does in 250ms and chrome does in 200ms :(