Remove TestFileLibTiff.test_save_many_compressed()

[akx]

Sibling of #9943, fell out of the same "hmm, what does pytest --durations say" suite.

It is the slowest test of the suite, saving the same image 10 000 times to find leaking file descriptors.

It was added in March 2023 in #6986, e953978, as a test for the commit 2299490 that fixed a file descriptor leak.

The TIFF cleanup path was subsequently cleaned up in June 2023 (#7199, e45da2a) and October 2024 (#8458, 7edf952) to avoid os.dup() at all, so the test isn't needed.

An alternative to removing the test is to make it count file descriptors. I tried that and couldn't reproduce a failure on the current Pillow, so that leads me to saying this isn't needed.

[radarhere]

The other PRs you mentioned didn't add any new tests regarding this functionality.

My personal feelings are to be pretty skeptical around 'the test isn't needed'. If we started pushing that idea further, the test suite would become very small quickly. I'm not saying there aren't ever reasons for getting rid of old tests, but I don't think test suite performance is a significant one. If the runtime of the test suite is a concern, then #9342 seems like it should be the first thing to address.

If anyone else would like to merge, go ahead, but those are my thoughts.

[akx]

The other PRs you mentioned didn't add any new tests regarding this functionality.

I mean... the broken functionality was removed in the fix PRs?

My personal feelings are to be pretty skeptical around 'the test isn't needed'.

I get that. But I looked and investigated, and I really don't think this test is needed with the current implementation. As noted, I can replace this with a test that counts fds over, say, 20 save() calls, if you do think TIFF saving is still leaking fds.

If we started pushing that idea further, the test suite would become very small quickly.

I don't think anyone is advocating pushing to make the test suite very small very quickly. But I think it's fair to say there are tests that aren't necessary, and I don't see reasons to spend CPU cycles (and in cases where tmp_path is disk-backed, SSD write cycles 😄) unnecessarily.

I'm not saying there aren't ever reasons for getting rid of old tests, but I don't think test suite performance is a significant one. If the runtime of the test suite is a concern, then #9342 seems like it should be the first thing to address.

I can take a look at that too. I locally run with pytest-xdist when suitable. #9933 touches upon the same things a bit. (To paraphrase it: stably measuring memory on PyPy will be somewhat futile, as it may decide that a function needs JIT compilation at any given moment, and secondly, the "tall" case of test_empty_image ends up allocating 700 megabytes of NULL pointers, and that sort of thing occasionally timeouts on the noisy-neighbors GitHub Actions CI VMs.

EDIT: I took a look. #9945.

I guess if someone from Pillow wants to reach out to Depot or Blacksmith for sponsored faster CI runners, that could be fun!

[radarhere]

If anyone is wondering why 10,000, it's to try and go over the limit of 8,192 - https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmaxstdio?view=msvc-170#remarks