[akx]

On my machine, this speeds up the entire test suite by ~8% on average, when running on all cores. (hyperfine)

~/b/Pillow (main) $ uv pip install -e . && hyperfine 'uv run -m pytest -nlogical --dist=worksteal'
Benchmark 1: uv run -m pytest -nlogical --dist=worksteal
  Time (mean ± σ):     11.237 s ±  0.323 s    [User: 61.079 s, System: 10.519 s]
  Range (min … max):   10.719 s … 11.919 s    10 runs

~/b/Pillow (test-speedups) $ uv pip install -e . && hyperfine 'uv run -m pytest -nlogical --dist=worksteal'
Benchmark 1: uv run -m pytest -nlogical --dist=worksteal
  Time (mean ± σ):     10.419 s ±  0.424 s    [User: 58.852 s, System: 10.216 s]
  Range (min … max):   10.048 s … 11.393 s    10 runs

• test_apng_save_split_fdat was spending time compressing data, but the premise of the test is to see whether large data is split across chunks correctly. The test now uses smaller data and a small MAXCHUNK, and tests the premise.
• Not a speedup, but 29ff5fc had replaced some patching with proper pytest monkeypatching, but left some stray globals in the files. Those get cleaned up.
• test_parser() is split up with parametrization (or in the explicitly failing case of PDFs, into a separate test...), so the different formats run in parallel (Run tests in parallel with pytest-xdist #9945 and all that).
• convert_to_comparable used get_flattened_data to convert a palette image to a list of numbers, just so it could be again interpreted as L bytes. Can just as well go with the bytes themselves (and Improve memory usage and performance for tobytes() #9938 will speed that up too).
• assert_image_similar now uses ImageChops.difference() to compute the difference map between 8bpp images in one multiband sweep. (This got faster in Speed up ImageChops operations #9738.) (ImageChops functions don't do non-8bpp at all; I might take a look at that.) Since many of the tests end up doing assert_image_similar, that's a nice win. (Improve memory usage and performance for tobytes() #9938 or Speed up image comparison and reduce memory usage #10030 will speed up assert_image_equal.) This is probably the source of most of the speedup here. :)

[akx]

The reason I started looking at assert_image_similar was this tracy-via-tracypy fragment:

[radarhere]

I know we have a difference of opinion on this, but I still don't see minor performance improvements in the test suite as a reason to start monkeypatching. I would rather test Pillow as it is with a real image.

[akx]

Pillow is not being monkeypatched. MAXBLOCK is a documented public API, this just sets it temporarily.

This is the same pattern as used in e.g. test_padded_idat in test_file_png.

[radarhere]

...when I said 'monkeypatching', I was referring to monkeypatch.setattr(ImageFile, "MAXBLOCK", 1024)

#5493 did that in order to avoid a large test image being stored permanently in the repository.

This change is about avoiding handling a 4160x870 image in memory, which doesn't seem that extreme to me.

[akx]

Right - here MAXBLOCK is being set to force writing smaller chunks to satisfy the premise of their test.

I didn't think about it also affecting reading, so if you'd like, we could undo the patch before reading them file back in? EDIT: Did that in a subsequent commit.

And, EDIT:

This change is about avoiding handling a 4160x870 image in memory, which doesn't seem that extreme to me.

No, it's not that extreme, but spending those cycles is also unnecessary for satisfying the premise of the test. Another option to speed up the test (while not doing anything about the memory cost) is to use the large image, and tell the encoder to not waste time compressing it.

[radarhere]

• Regarding the 'stray globals', I've cherry-picked that into Remove unnecessary code #10292
• Regarding convert_to_comparable(), looking at that code, I think it's incorrect to compare two P images by discarding their palette data. I think it would be better to convert them to RGB first. See Convert P images to RGB before comparing #10290
• For the assert_image_similar() speedup, I found that because histogram() only groups data into 256 bins, the computed difference of 255. For I mode images, the difference could be much larger than that. Obviously, that flaw already exists in main, and yes, our epsilon threshold should never be that high, but I would still not like to add code dedicated to I mode images in there, as it would give the impression that we considered this mode and deemed the output correct.
• For test_apng_save_split_fdat(), as I've said in comments above, I don't think the test is extreme, and so would prefer simplicity and realism.
• I'm tempted by the parametrization of test_parser - not for performance, but just to split up a large test - but don't really like having the formats listed in one place with their skip conditions and then having the specific conditions for those formats in another.