If height is scaled down significantly more than width, resize vertically first

[radarhere]

Refining #9524, applying a solution in C, rather than Python

[radarhere]

I merged main in, and Benchmark passed, but I don't know how if/how much the improvement is.

[akx]

According to CodSpeed, ~4% faster, so could be measurement noise and as such unreported.

[radarhere]

Ok. The benchmark tests don't cover reducing height but not width, so it at least confirms that this doesn't make things worse for other scenarios.

[hugovk]

There's a performance regression for reducing very tall images also with a width reduction:

❯ python -c "
  import timeit
  from PIL import Image
  im = Image.new('RGB', (50, 500000))
  print(min(timeit.repeat(lambda: im.resize((40, 1000)), number=5, repeat=3)) / 5 *
  1000, 'ms')
  "
155.0545250007417 ms

❯ python -c "
  import timeit
  from PIL import Image
  im = Image.new('RGB', (50, 500000))
  print(min(timeit.repeat(lambda: im.resize((40, 1000)), number=5, repeat=3)) / 5 *
  1000, 'ms')
  "
212.88325839996105 ms

[hugovk]

Possible memory leak here: if the second pass's ImagingNewDirty fails, imTemp is overwritten with NULL before we goto end, so the intermediate image from the first pass (now only referenced by imIn) is never deleted. We had an ImagingDelete(imTemp) call before.

[radarhere]

Good catch. I've pushed a commit.

[codspeed-hq]

Merging this PR will not alter performance

✅ 603 untouched benchmarks
⏩ 335 skipped benchmarks¹

---

_{Comparing radarhere:resize (eb69fd6) with main (6b5a7db)}

Footnotes

1. 335 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[radarhere]

There's a performance regression for reducing very tall images also with a width reduction

Ok, that should be fixed now.