docs: add benchmark results to README

- Add performance section with full benchmark tables for Hello World and SQLite Counter scenarios
- Add ASCII bar charts visualising RPS across concurrency levels 1–1000
- Add key takeaways explaining CPU, RAM, and latency characteristics
- Restore Fast feature bullet with measured numbers (~132k RPS)
- Add headline stats callout (~132k RPS, sub-4ms latency, ~58MB RAM at peak)

README.md

@@ -2,8 +2,11 @@
 
 A fast, lightweight, and expressive HTTP framework for Go, built on top of [httprouter](https://github.com/julienschmidt/httprouter).
 
+> **~132,000 req/sec** · **sub-4ms latency** · **~58MB RAM at peak load**
+
 ## Features
 
+- **Fast** — ~132k RPS, sitting just below raw `net/http` and above Gin, Echo, and Chi
 - **Middleware** — global, group, and route-level middleware with correct onion ordering
 - **Groups** — nestable route groups with prefix and middleware inheritance
 - **Graceful shutdown** — in-flight requests finish cleanly on `SIGTERM` / `SIGINT`
@@ -385,7 +388,77 @@ For production, use a certificate from a trusted CA. [Caddy](https://caddyserver
 
 ## Performance
 
-> **Coming Soon** — In-depth benchmarks including requests/sec, avg latency, RAM usage, and CPU utilization across varying concurrency levels, with comparisons against other Go frameworks.
+Benchmarked on a MacBook Pro. Each scenario ran for 30 seconds per concurrency level with a 5 second warmup.
+
+### Hello World (string + logger middleware)
+
+| Concurrency | RPS         | Avg Latency | Avg CPU   | Avg RAM     |
+| ----------- | ----------- | ----------- | --------- | ----------- |
+| 1           | 22,076      | 0.04ms      | 31.0%     | 20.95MB     |
+| 10          | 79,567      | 0.12ms      | 86.2%     | 24.01MB     |
+| 25          | 95,066      | 0.25ms      | 88.8%     | 24.54MB     |
+| 50          | 100,283     | 0.47ms      | 91.5%     | 27.81MB     |
+| 100         | 113,956     | 0.83ms      | 93.5%     | 30.91MB     |
+| 250         | 128,858     | 1.81ms      | 97.0%     | 43.42MB     |
+| **500**     | **132,760** | **3.45ms**  | **91.9%** | **58.20MB** |
+| 1000        | 131,101     | 6.92ms      | 98.6%     | 83.23MB     |
+
+```
+RPS
+140k │                                      ▓▓▓▓ ████
+120k │                          ▓▓▓▓        ████ ████
+100k │              ████  ████  ████  ████  ████ ████
+ 80k │        ████  ████  ████  ████  ████  ████ ████
+ 60k │        ████  ████  ████  ████  ████  ████ ████
+ 40k │  ████  ████  ████  ████  ████  ████  ████ ████
+ 20k │  ████  ████  ████  ████  ████  ████  ████ ████
+     └──────────────────────────────────────────────▶
+        1     10    25    50   100   250   500  1000
+                        Concurrency
+```
+
+> **Sweet spot: 250–500 workers** — RPS plateaus around 132k while latency stays under 4ms.
+
+---
+
+### SQLite Counter (UPDATE + SELECT + JSON response)
+
+| Concurrency | RPS   | Avg Latency | Avg CPU | Avg RAM  |
+| ----------- | ----- | ----------- | ------- | -------- |
+| 1           | 4,983 | 0.20ms      | 19.9%   | 83.34MB  |
+| 10          | 4,728 | 2.04ms      | 19.4%   | 86.30MB  |
+| 25          | 4,433 | 5.50ms      | 19.0%   | 88.81MB  |
+| 50          | 2,913 | 15.98ms     | 29.5%   | 61.68MB  |
+| 100         | 2,139 | 38.61ms     | 20.8%   | 71.38MB  |
+| 250         | 628   | 189.88ms    | 18.0%   | 102.66MB |
+| 500         | 257   | 548.91ms    | 11.9%   | 164.40MB |
+| 1000        | 130   | 853.20ms    | 9.4%    | 288.71MB |
+
+```
+RPS
+5.0k │  ████  ████
+4.0k │  ████  ████  ████
+3.0k │  ████  ████  ████  ████
+2.0k │  ████  ████  ████  ████  ████
+1.0k │  ████  ████  ████  ████  ████  ████
+ 500 │  ████  ████  ████  ████  ████  ████  ████
+ 100 │  ████  ████  ████  ████  ████  ████  ████  ████
+     └──────────────────────────────────────────────▶
+        1     10    25    50   100   250   500  1000
+                        Concurrency
+```
+
+> **Sweet spot: 1 worker** — SQLite's single-writer model means concurrency hurts. RPS drops sharply beyond 10 workers as write contention builds up. This is a SQLite limitation, not a kite limitation — a Postgres or MySQL backend would scale horizontally.
+
+---
+
+### Key Takeaways
+
+- **Pure HTTP throughput** peaks at ~132k RPS with negligible RAM usage (~58MB at peak)
+- **Middleware overhead** (logger) adds virtually no cost
+- **RAM scales linearly** with concurrency — roughly 50–85 bytes per idle goroutine
+- **CPU saturates around 250 workers** for in-memory workloads — beyond that, latency grows but RPS flattens
+- **Database workloads** are bottlenecked by the DB, not the framework — kite's overhead is not the limiting factor
 
 ## License