11c3520507
- New experiment: profile_memory_usage.py (tracemalloc + RSS at 1-100 sessions) - Results: 7.7 KB/session (23% under prior 10KB estimate) - New paper section §4.6 with scaling table - Updated §5.6 scalability with measured data instead of theory - Version bump to 0.1.3-draft
75 lines
2.5 KiB
Markdown
75 lines
2.5 KiB
Markdown
# Memory Profiling Results: Per-Session Overhead
|
||
|
||
**Date:** 2026-04-13
|
||
**Hardware:** macOS, CPython 3.12, tracemalloc + resource module
|
||
**Bridge version:** feat/multi-user-bridge (HEAD)
|
||
|
||
## Configuration
|
||
|
||
| Parameter | Value |
|
||
|-----------|-------|
|
||
| Session scales tested | 1, 5, 10, 20, 50, 100 |
|
||
| Messages per session | 20 (default history window) |
|
||
| History windows tested | 10, 20, 50, 100, 200 |
|
||
| CrisisState instances | 10,000 |
|
||
|
||
## Results: Session Scaling
|
||
|
||
| Sessions | RSS Delta (MB) | tracemalloc (KB) | Per-Session (bytes) |
|
||
|----------|---------------|------------------|---------------------|
|
||
| 1 | 0.00 | 19.5 | 20,008 |
|
||
| 5 | 0.06 | 37.4 | 7,659 |
|
||
| 10 | 0.08 | 74.9 | 7,672 |
|
||
| 20 | 0.11 | 150.0 | 7,680 |
|
||
| 50 | 0.44 | 375.4 | 7,689 |
|
||
| 100 | 0.80 | 757.6 | 7,758 |
|
||
|
||
**Key finding:** Per-session memory stabilizes at ~7.7 KB across all scales ≥5 sessions. The first session incurs higher overhead due to Python import/class initialization costs. At 100 concurrent sessions, total memory consumption is under 1 MB — well within any modern device's capacity.
|
||
|
||
## Results: History Window Scaling
|
||
|
||
| Configured Window | Actual Messages | Total (KB) | Bytes/Message |
|
||
|-------------------|-----------------|------------|---------------|
|
||
| 10 | 20 | 17.2 | 880 |
|
||
| 20 | 40 | 28.9 | 739 |
|
||
| 50 | 100 | 71.3 | 730 |
|
||
| 100 | 200 | 140.8 | 721 |
|
||
| 200 | 400 | 294.3 | 753 |
|
||
|
||
**Key finding:** Memory per message is ~730–880 bytes (includes role, content, timestamp, room). Scaling is linear — doubling the window doubles memory. Even at a 200-message window with 400 stored messages, a single session uses only 294 KB.
|
||
|
||
## Results: CrisisState Overhead
|
||
|
||
| Metric | Value |
|
||
|--------|-------|
|
||
| Instances | 10,000 |
|
||
| Total memory | 1,645.8 KB |
|
||
| Per-instance | 168.5 bytes |
|
||
|
||
**Key finding:** CrisisState overhead is negligible. Even at 10,000 instances, total memory is 1.6 MB. In production with 100 sessions, crisis tracking adds only ~17 KB.
|
||
|
||
## Corrected Scalability Estimate
|
||
|
||
The paper's Section 5.6 estimated ~10 KB per session (20 messages × 500 bytes). Measured value is **7.7 KB per session** — 23% more efficient than the conservative estimate.
|
||
|
||
Extrapolated to 1,000 sessions: **7.7 MB** (not 10 MB as previously estimated).
|
||
The system could theoretically handle 10,000 sessions in ~77 MB of session state.
|
||
|
||
## Reproduction
|
||
|
||
```bash
|
||
python experiments/profile_memory_usage.py
|
||
```
|
||
|
||
## JSON Results
|
||
|
||
```json
|
||
{
|
||
"per_session_bytes": 7758,
|
||
"per_message_bytes": 739,
|
||
"crisis_state_bytes": 169,
|
||
"rss_at_100_sessions_mb": 0.8,
|
||
"sessions_per_gb_ram": 130000
|
||
}
|
||
```
|