This is not a completely fair comparison: isCanvasEqual repeatedly allocaes a typed array, while isDataURLEqual allows for memoizing the Data URL. Also, as you alluded at between the lines earlier: when two canvases are equal isCanvasEqual needs to compare *all* pixels, whereas a lot of browsers have some form of optimization for string comparisons IIRC (because they're immutable, a pointer comparison often suffices under the hood when they're equal). So performance metrics will also vary depending on whether the canvases are expected to be equal - if we expect isCanvasEqual to bail early *and* get rid of the typed array allocation it might still beat isDataUrlEqual Hold up, I'll write a fork with a third comparison point (like, isFloat64Equal, or something).

(just noticed that you mentioned the worst-case in the last paragraphs below, somehow missed that before, sorry) Here's what I got so far: https://observablehq.com/d/37d1bf292f23ccb6 I think there's something wrong with how I adapted the benchmarking code, because the array-comparison comes out faster in all cases on my laptop, which makes no sense: it should be equally slow to isCanvasEqual for the N=1 case, no? (ended up using Uint32 because Float64 doesn't work due to NaN values)

Thanks a lot! It's a great improvement! I merged your contribution and added attribution.

Glad to be useful! But now the overal narrative of the writing is a bit confusing, since it doesn't take into account the new function yet 😅

You're right. I added some text in the performance section. It's not the best notebook of the year, but the information is here for the interested reader.