Performance/speed comparison with BlurHash

[ToshY]

The documentation/demo states the following:

Much faster to encode and decode

Howmuch faster compared to BlurHash? If you've done tests to compare performance/speed between ThumbHash and BlurHash, it would be nice to show these results.

[evanw]

I should probably remove that part of the website. I don't want that to be the focus of this. Partially because the performance doesn't matter too much (encode typically happens once and is stored, and decode is pretty trivial), partially because optimal performance isn't even a goal (it'd be pretty trivial to speed this up even more with SIMD or a hand-rolled cos implementation, but that goes against the goal of having simple code), and partially because BlurHash is slow for uninteresting reasons.

Some data points to answer your question, since I should still back it up (1 μs is a microsecond, which is 0.000001 seconds):

• Encode:

  Language	BlurHash encode	ThumbHash encode	ThumbHash speedup
  JavaScript	6,142 μs	622 μs	9.9x faster
  Swift (debug)	43,180 μs	1,502 μs	28.8x faster
  Swift (release)	1,859 μs	299 μs	6.2x faster

• Decode:

  Language	BlurHash decode	ThumbHash decode	ThumbHash speedup
  JavaScript	185 μs	166 μs	1.1x faster
  Swift (debug)	3,395 μs	405 μs	8.4x faster
  Swift (release)	79 μs	63 μs	1.2x faster

One big reason BlurHash is currently slower is that their sRGBToLinear function should really be implemented as a lookup table but isn't. That's a 2x speedup to BlurHash right there. I'm sure there are other easy wins too. I wouldn't be surprised if it's possible to make a BlurHash implementation that's just as fast as (or even faster than) ThumbHash since they are doing pretty similar things.

Another reason BlurHash's Swift implementation is so slow in debug builds is that they are using for-in loops instead of while loops (see e.g. woltapp/blurhash#215). This is a really dumb performance issue with the current Swift compiler implementation. You could argue that debug performance doesn't matter and that readability should be prioritized as long as release performance is good, so maybe BlurHash shouldn't even be changed. Personally I value quick iteration cycles with debug builds so I have tuned ThumbHash's code for that.