Ideas for RSGI 2.0: reducing Python object overhead & moving more work to Rust

[albertedwardson]

With recent Python releases, networking and async I/O on the Python side have been getting consistently faster. As a result, the performance bottleneck for Rust-based servers seems to shift away from networking towards Rust/Python boundary, especially around serialization and object marshaling

And RSGI 1.X relies on creating and passing a fair number of Python objects (scopes, headers, protocol wrappers, etc.) per request.

I'm opening this issue to to hear maintainers’ and other contributors’ perspectives and to start an open discussion around whether a future RSGI 2.0 could push more work fully into Rust and further reduce Python object involvement.

Possible directions (not a concrete proposal yet):

• Passing typed / binary request buffers instead of Python mappings
• Zero-copy or low-copy access to request bodies and headers
• Streaming and WebSocket APIs that avoid per-chunk/frame Python callbacks
• Treating Python primarily as application logic, not part of the protocol machinery

This is a purely exploratory idea. I don’t currently have concrete issues with RSGI as it exists today. These thoughts came up while reading through how RSGI works and thinking about where future bottlenecks might move as Python networking performance continues to improve.

Thanks for your work and attention!

Note: this text was written with help of AI, so I apologise in advance if it feels weird

[gi0baro]

I'm a bit confused on the premise, as you say:

With recent Python releases, networking and async I/O on the Python side have been getting consistently faster.

but, even if that's true – not sure where this premise comes from – RSGI and Granian never interact with the networking stack in the Python side of things. So when you say:

As a result, the performance bottleneck for Rust-based servers seems to shift away from networking

I'm not sure what do you mean, given Python networking plays 0 role in RSGI.

Also, when you say

the performance bottleneck for Rust-based servers seems to shift away from networking towards Rust/Python boundary, especially around serialization and object marshaling.
And RSGI 1.X relies on creating and passing a fair number of Python objects (scopes, headers, protocol wrappers, etc.) per request.

do you have any numbers that validate this? Or, in other words, how can you be sure the bottleneck in RSGI is object marshaling without any profiling? 'cause to my knowledge, the biggest bottleneck in Granian (and thus also in the RSGI protocol) are GIL acquisition time and/or contention, and asyncio harness (tasks, futures, handles, and all the relevant operation that has to be done in the Python event loop just to run a coroutine).

[albertedwardson]

Thanks for the detailed response! I think I mixed a few ideas together and that made the premise confusing.

First, regarding "Python networking getting faster":
Even if Python networking itself plays no role in RSGI or Granian, what I was trying to say is not that RSGI benefits from Python networking improvements, but that as CPython improves in general, the relative cost distribution inside a Python web stack may shift. My assumption is that more and more time ends up in CPU-bound parts like parsing, data movement, and boundary crossings.*

Second, about object marshaling and lack of numbers:
Well, I don’t have profiling data that proves object marshaling is the bottleneck in RSGI today*. This is purely a hypothesis based on a general rule of thumb: less Python involvement tends to be faster, especially in data-heavy paths. This is speculation, not a conclusion.

My thinking was: if it’s possible to share something closer to a C-like struct between Rust and Python (with minimal or zero marshalling), that might reduce overhead compared to constructing Python objects, even if that overhead is not currently dominant.

Third, regarding GIL and asyncio overhead. What I was wondering is whether a future RSGI variant could describe only data handling and request/response exchange, without assuming or coupling to a specific async runtime or asyncio semantics

In other words, not trying to solve the event loop problem, but also not baking it into the protocol boundary more than necessary.

Lastly, on real-world performance observations:

I noticed that in benchmarks like
https://github.com/huynguyengl99/python-api-frameworks-benchmark
Granian sometimes performs less efficiently than pure-Python Uvicorn. I also saw similar behavior when switching from Uvicorn to Granian at work* : RPS was similar, but latency increased.

I’m not claiming this is caused by RSGI or object marshaling - just that it made me think more about where the overheads actually are and whether there’s room to experiment with a lower-level interface.

To be clear, I’m not asserting current bottlenecks without profiling. This idea came purely from reading the spec and thinking "what if we pushed this even further"

I mainly wanted to sanity-check this line of thinking with maintainers and hear why it may or may not make sense.

.* - "trust me bro" takes, sorry