Last 12 weeks · 8 commits
2 of 6 standards met
Adds io_uring support for Linux performance optimization. Performance WebSocket benchmark results: tokio: ~4ms for 100 echo messages io_uring: ~3ms for 100 echo messages 20% performance improvement Implementation feature flag with conditional compilation Drop-in replacement for types Task-based AsyncRead/AsyncWrite adapter for io_uring compatibility Full WebSocket protocol support through existing APIs Usage Testing Requirements Linux 5.11+, x86_64/aarch64. Optional dependency on . Without the feature flag, uses standard tokio with zero overhead.
Repository: denoland/fastwebsockets. Description: A fast RFC6455 WebSocket implementation Stars: 1075, Forks: 103. Primary language: Rust. Languages: Rust (85%), C (9.5%), JavaScript (3.8%), Makefile (1.7%). License: Apache-2.0. Homepage: https://docs.rs/fastwebsockets/ Open PRs: 9, open issues: 13. Last activity: 1mo ago. Community health: 37%. Top contributors: littledivy, bartlomieju, mmastrac, erebe, kaniini, Avi-D-coder, Caiooooo, dxvid-pts, jembishop, JinWeiTan and others.
Improves memory efficiency and reduces CPU overhead in the WebSocket writing and fragment processing logic. Shifted to ownership transfers and in-place mutations and reduced the number of heap allocations and eliminate unnecessary buffer zero-initializations. Operation After this PR Write Header Allocation + Copy Decode Text $O(1)$ Ownership transfer / Truncate
Hi! I’m trying to eliminate memory allocations when using my websocket handler, but read_frame currently allocates a new Vec for (almost) every incoming frame. Would it be possible to provide an API variant that lets users supply a buffer to read into, avoiding these allocations? Or do you know of any workaround for this issue?