Performance
HORUS is designed for performance by default — zero-copy shared memory IPC, lock-free ring buffers, and priority-based scheduling. Most applications need no tuning.
Optimize only after your system works correctly. Premature optimization in robotics is dangerous — a fast controller that computes the wrong output is worse than a slow one that's correct.
Quick Reference
| Metric | HORUS (typical) | ROS2 (typical) |
|---|---|---|
| Same-thread IPC | ~23 ns | N/A |
| Cross-thread IPC (1:1) | ~155 ns | 20-50 us |
| Cross-process IPC | ~180 ns | 50-100 us |
| Scheduler tick overhead | ~1 us per node | 10-50 us per node |
| Node scaling (100 nodes) | +14% overhead | +200-400% overhead |
| Topic scaling (1000 topics) | 0% degradation | Significant |
Guides
- Optimization Guide — When and how to tune: message sizes, buffer capacities, tick rates, CPU pinning, memory layout
- Benchmarks — Latency, throughput, and scalability measurements comparing HORUS to alternatives
What HORUS Optimizes For You
| Feature | How | Tunable? |
|---|---|---|
| IPC latency | Shared memory (no serialization for same-machine) | Buffer size via Topic::with_capacity() |
| Message passing | Lock-free ring buffer | Slot count and size |
| Scheduling | Priority-ordered tick loop | .order(), .rate(), execution classes |
| Large data | Pool-backed allocation (Image, PointCloud, Tensor) | Pool size |
| Real-time | Dedicated RT threads, SCHED_FIFO | .budget(), .deadline(), .on_miss() |
See Also
- Scheduler Configuration — Advanced tick rate and thread pool tuning
- RT Setup — Linux real-time kernel configuration
- API Cheatsheet — Quick reference for all APIs