Improve FileResponse performance by always using aiohttp's sendfile fallback if native sendfile is not available

[tarasko]

I made a curious finding while looking at sendfile benchmarks.
aiohttp's _sendfile_fallback is much more efficient than asyncio's loop.sendfile fallback mode for large files.

Unfortunately, I had to use a non-public asyncio API to reliably detect when loop provides native sendfile.

Just reject this PR if you are not comfortable with it.

What do these changes do?

Make aiohttp to use its own sendfile fallback instead of loop fallback when native sendfile is not available for the transport.

aiohttp version of _sendfile_fallback is much more efficient and agile than asyncio's fallback.
Both implementations use another thread to read chunks:

        chunk = await loop.run_in_executor(
            None, self._seek_and_read, fobj, offset, min(chunk_size, count)
        )

Because of the GIL and time it takes to transfer task to/from another thread it is much more efficient to do it with bigger chunk size.
asyncio has hardcoded chunk size of 16 Kb
aiohttp chunk size is 256 Kb by default and can be adjusted.

Are there changes in behavior for the user?

No

Is it a substantial burden for the maintainers to support this?

No, aiohttp _sendfile_fallback is currently used anyway if compression is enabled, or with uvloop SSL transports.

Related issue number

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• Add yourself to CONTRIBUTORS.txt
• Add a new news fragment into the CHANGES/ folder

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.95%. Comparing base (db5c238) to head (1804c99).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #12945   +/-   ##
=======================================
  Coverage   98.95%   98.95%           
=======================================
  Files         131      131           
  Lines       47998    48002    +4     
  Branches     2494     2495    +1     
=======================================
+ Hits        47498    47502    +4     
  Misses        376      376           
  Partials      124      124           

Flag	Coverage Δ
Autobahn	22.27% <0.00%> (-0.01%)	⬇️
CI-GHA	98.90% <100.00%> (+<0.01%)	⬆️
OS-Linux	98.66% <100.00%> (+<0.01%)	⬆️
OS-Windows	97.03% <100.00%> (+<0.01%)	⬆️
OS-macOS	97.94% <100.00%> (-0.01%)	⬇️
Py-3.10	98.14% <100.00%> (+<0.01%)	⬆️
Py-3.11	98.41% <100.00%> (+<0.01%)	⬆️
Py-3.12	98.50% <100.00%> (+<0.01%)	⬆️
Py-3.13	98.46% <100.00%> (-0.01%)	⬇️
Py-3.14	98.48% <100.00%> (-0.01%)	⬇️
Py-3.14t	97.57% <100.00%> (-0.01%)	⬇️
Py-pypy-3.11	97.43% <100.00%> (-0.02%)	⬇️
VM-macos	97.94% <100.00%> (-0.01%)	⬇️
VM-ubuntu	98.66% <100.00%> (+<0.01%)	⬆️
VM-windows	97.03% <100.00%> (+<0.01%)	⬆️
cython-coverage	38.03% <50.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will improve performance by ×2.1

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 3 improved benchmarks
✅ 80 untouched benchmarks
⏩ 83 skipped benchmarks¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	test_simple_web_file_sendfile_fallback_response[tcp-large]	128.5 ms	38.8 ms	×3.3
⚡	test_simple_web_file_response[ssl-large]	243.8 ms	149.7 ms	+62.85%
⚡	test_simple_web_file_sendfile_fallback_response[ssl-large]	243 ms	149.9 ms	+62.15%

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing tarasko:feature/sendfile_fallback_opt (1804c99) with master (db5c238)}

Footnotes

1. 83 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. ↩

[Dreamsorcerer]

aiohttp's _sendfile_fallback is much more efficient than asyncio's loop.sendfile fallback mode for large files.

Is it possible that the aiohttp version can be upstreamed into asyncio?

[tarasko]

aiohttp's _sendfile_fallback is much more efficient than asyncio's loop.sendfile fallback mode for large files.

Is it possible that the aiohttp version can be upstreamed into asyncio?

It is all about chunk size, not the implementation itself.

I'll open an issue there. I guess they would need to add a new argument fallback_chunk_size to loop.sendfile and maybe adjust default value

loop.sendfile(transport, file, offset=0, count=None, *, fallback=True, fallback_chunk_size=256*1024)

The change is rather trivial, but probably, wouldn't be available before 3.16,

The thing is, even with 3.16 this wouldn't let to remove _sendfile_fallback. It will be necessary at least for compressed responses. So, I though, maybe embrace it and use it as much as possible?