gh-117151: IO performance improvement, increase io.DEFAULT_BUFFER_SIZE to 128k

[morotti]

See discussion gh-117151

This patch adjusts the buffer size. That gives 3 to 5 times I/O performance improvement on modern hardware.

• increase io.DEFAULT_BUFFER_SIZE to 128k
• fix open() to use max(st_blksize, io.DEFAULT_BUFFER_SIZE)

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[morotti]

@serhiy-storchaka hello, you were kind to review my first PR for buffering performance (118037), would you be able to review this PR too?

[eendebakpt]

@morotti You still need to write a news entry for the PR. For your other PR this is was not required, but due to the performance impact of this PR I think we should. The most convenient way for this is to click on the Details button next to bedevere/news of the CI checks which will open a tool to add the news entry. For more information also see https://devguide.python.org/core-developers/committing/#updating-news-and-what-s-new-in-python

The CLA is not yet working, but it worked for the other PR (which was created after this one), so maybe it will resolve itself automatically in a couple of days

[eendebakpt]

Pinging @benjaminp as expert on io. Could you review this PR? Are there other benchmarks (besides the one in the corresponding issue) we can perform to test this PR?

[morotti]

Thank you for reviewing,

The CLA check is green now and I added a news entry.

[morotti]

@eendebakpt @benjaminp could you review?

[eendebakpt]

@eendebakpt @benjaminp could you review?

@morotti The PR looks good from my side, but I am no core dev so I cannot approve. Currently many core devs are at pycon US, so I think we should wait a bit more. If in a few weeks there has been no further response, we can post a message to discourse (see https://devguide.python.org/getting-started/pull-request-lifecycle/#reviewing).

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @itamaro for commit 3668d1a 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @itamaro for commit 28e7bb7 🤖

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[erlend-aasland]

Requesting Serhiy's review, since he reviewd the other linked (and merged) PR #118037.

[serhiy-storchaka]

I was convinced that such a change could be beneficial.

But for the case if it has unexpected effect, please ask on https://discuss.python.org/. Update also the C implementation of open() which is used by default.

[serhiy-storchaka]

Please do not use rebase and force-push. It makes reviewing more difficult.

[morotti]

apologies, I thought I had to squash the new commits and force push.

[morotti]

all adjusted

• found and corrected another code path in the C API that was using the block size
• added a test
• updated the documentation

[cmaloney]

@morotti

1. winconsoleio picks this up (https://github.com/python/cpython/blob/main/Modules/_io/winconsoleio.c#L425), and has a past bug that there is a cap (https://bugs.python.org/issue11395, https://github.com/python/cpython/blob/main/Modules/_io/winconsoleio.c#L1027-L1031). I don't think this PR breaks that (winconsoleio in write() cuts up too big of writes), but likely the default buffer size there shold be separated from this new bigger constant which is always going to require splitting write calls.
2. do you have any performance numbers around local disk read() with this change? (Curious for small and large local cached file)

[morotti]

thanks, having a look,

looking at the old threads, the bug with winconsole destroying large input was reported in 2010.
it was Windows XP era (2002-2014), it's not claer if the bug still applies to active windows versions. the limitation is no longer listed in the MSDN page.
support for windows XP was dropped forever ago, support for windows 7 was dropped with the python 3.11 release in 2022.

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1232
Correction: the ​MSDN documentation for WriteConsoleW does document a length limitation, but it says 64 KiB (which would be 32767 UTF-16 characters and a terminating NUL), not 26608 characters. The fix is the same regardless; I'll limit it to 10000 [UTF-16] characters.

[morotti]

@cmaloney

I've adjusted winconsole to have a different default buffer size.
I've added comments with what I could gather from the threads.

for the impact on read(), it's quite variable.

• larger write() gives 3 to 5 times performance improvements, just from the I/O.
• larger read() gives barely a few percent improvements (less than 10% on my machines), just from the I/O. the filesystem is really saving us from this terrible code!

HOWEVER, that's just for the I/O. the app will do something with the chunks and any python code that is doing not-so-small operation on each chunk can get a very large impact.

we've found the bug in pip twice, pypa/pip#12810
there is code to download packages in 10240 bytes chunks + there is code to read package files and compute the checksum in io.DEFAULT_BUFFER_SIZE=8192 chunks.

the download code is obliterated by the small chunks. it's calling some code and updating a progress bar with each chunk, as much as 30% of the pip runtime is updating the progress bar when it's downloading packages 🫨.
the hashing code is merely hashlib.update(buffer) in a loop. it's single digit percent improvement for using larger chunks.
so in the same app, you get both a case where large chunks make an enormous difference and a not so much difference.

it's worthwhile to note that I've found python 3.11 to be 4 times faster than previous versions in tight loop and list comprehension. older python versions would get much more impact from small chunks, due to the larger overhead of many more loop iterations and function calls.

[cmaloney]

Soungs good to me. re: Windows, I dug into the docs and history a bit and it looks like with Windows 8+ it's not necessary anymore. I'm seeing if it's possible to remove the special case in gh-121940.

[cmaloney]

This needs to merge changes with #123412 (the stat result is now stashed as a member so can do a number of optimizations with it)