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
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):
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