@mourner any chance to get this merged?
I think this is an elegant solution to this issue, it definitely improves the situation if not fully solves it.

Before we merge, the last thing left to do is to check whether and how much it affects performance

Here's the time in milliseconds for each unit test, as an average of 10 runs:

@NathanMOlson a bit too variable to make a conclusion... e.g. could we try a median of 1000 runs after a warmup of 100 runs?

@NathanMOlson a bit too variable to make a conclusion... e.g. could we try a median of 1000 runs after a warmup of 100 runs?

Sure. Here you go. Another change I mage is to only profile the match calls instead of the whole test (which includes other expensive tasks like reading images).

Since this is quite a bit slower, I did a run after changing the background color to

    const rBackground = 255;
    const gBackground = 255;
    const bBackground = 255;

Here's the results:

There is very little change between the variable background and the constant background, so I don't think we can expect performance gains from changing the background function. There's not much else changed in this PR, so my guess is that adding the third argument to blend() is responsible for the slowdown.

@NathanMOlson a bit too variable to make a conclusion... e.g. could we try a median of 1000 runs after a warmup of 100 runs?

@mourner You misunderstood the table. Each line is not a single test run, but an average of 10 runs for a single unit test. Each line is different because each unit test is different and takes a different amount of time. The variability is actually quite low.

However, the new tables (median from 1000 runs after 100 runs warmup) are better both because they have more runs and because they exclude the parts of the unit tests other than match().

@NathanMOlson I understood the table, just thought 10 runs aren't nearly enough to measure the difference reliably.

OK, since the difference is significant, let me play with this PR a bit more before we can merge — curious to find the culprit / way to optimize this.

Also, some of the tests don't even have semitransparent pixels, which makes it forego the blend calls altogether, which wouldn't produce such a difference, so this might be something with the benchmarking setup...

JS perf can be weird sometimes

I think this must be one of those cases. I've played around with it and haven't been able to improve it or get a clear understanding of what is causing the slowdown.

@mourner Any more thoughts about this?

@mourner Any update?