gavindiaz/polyfill-rs
1
0
Fork 0
mirror of https://github.com/floor-licker/polyfill-rs.git synced 2026-08-19 15:38:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: update README.md

Browse Source
This commit is contained in:
floor-licker
2026-01-30 21:30:10 -05:00
parent d4e240714c
commit 65bab0d3c1
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+1 -1
View File
@@ -8,7 +8,7 @@ A high-performance drop-in replacement for `polymarket-rs-client` with latency-o
At the time that this project was started, `polymarket-rs-client` was a Polymarket Rust Client with a few GitHub stars, but which seemed to be unmaintained. I took on the task of creating a Rust client which could beat the benchmarks quoted in the README.md of that project, with the added constraint of also maintaining zero alloc hot paths. At the time that this project was started, `polymarket-rs-client` was a Polymarket Rust Client with a few GitHub stars, but which seemed to be unmaintained. I took on the task of creating a Rust client which could beat the benchmarks quoted in the README.md of that project, with the added constraint of also maintaining zero alloc hot paths.
I also want to take a moment to clarify what zero-alloc means because I've now recieved double digit messages about this on twitter/x and telegram. In general, zero alloc means either zero alloc in hot paths (which can be a bit more arbitrary) or atlernatively it can mean zero alloc ater init/warm-up, which is the objective of this repository. Succinctly that means that **the per-message handling loop never touches the heap**. I also want to take a moment to clarify what zero-alloc means because I've now recieved double digit messages about this on twitter/x and telegram. In general, zero alloc means either zero alloc in hot paths (which can be a bit more arbitrary) or atlernatively it can mean zero alloc after init/warm-up, which is the objective of this repository. Succinctly that means that **the per-message handling loop never touches the heap**.
Notably order book paths that introduce new allocations by design: Notably order book paths that introduce new allocations by design:
- First time seeing a token/book (HashMap insert + key clone): `src/book.rs:~788` - First time seeing a token/book (HashMap insert + key clone): `src/book.rs:~788`