TxsharDev/Redline
GitHub: TxsharDev/Redline
Redline 是一个 Rust 编译时性能保障库,通过宏注解在编译阶段强制函数满足延迟、分配和系统调用等性能约束,违反即触发致命编译错误。
Stars: 0 | Forks: 0
Cross the performance line. Won't compile.
Quick Start | Constraints | Cost Model | Use Cases | Limitations
Rust 在编译时证明内存安全。Redline 在编译时强制执行性能边界。 ``` #[redline(latency = "< 1ms")] fn process_request(req: &Request) -> Response { // compiler checks: estimated worst-case for every visible path < 1ms } ``` 如果有任何代码路径可能超出边界,该函数将无法编译。不是警告。不是 lint。而是致命的编译器错误。 ## 安装说明 ``` [dependencies] redline = "0.1" ``` ## 用法 ``` use redline::redline; // Latency bound: estimated worst-case must be under 1ms #[redline(latency = "< 1ms")] fn fast_handler(data: &[u8]) -> u64 { let mut sum: u64 = 0; for i in 0..100 { sum += data.get(i).copied().unwrap_or(0) as u64; } sum } // Zero allocations: no Vec, String, Box, HashMap, clone, collect #[redline(allocs = 0)] fn hot_path(a: f64, b: f64) -> f64 { a * a + b * b } // Zero syscalls: no file I/O, no network, no println #[redline(syscalls = 0)] fn pure_compute(x: i32) -> i32 { x * x + 2 * x + 1 } // Combined: all constraints checked together #[redline(latency = "< 100us", allocs = 0, syscalls = 0)] fn critical_section(data: &[u8]) -> u64 { let mut h: u64 = 0; for i in 0..64 { h ^= data.get(i).copied().unwrap_or(0) as u64; } h } ``` ## 当你违反规则时会发生什么 ``` #[redline(allocs = 0)] fn oops() -> String { String::from("hello") // allocates } ``` ``` error: redline: function `oops` has 1 allocation(s), limit is 0 --> src/main.rs:3:1 | 3 | #[redline(allocs = 0)] | ^^^^^^^^^^^^^^^^^^^^^^ ``` ``` #[redline(syscalls = 0)] fn also_oops() { println!("this is I/O"); // syscall } ``` ``` error: redline: function `also_oops` has 1 syscall(s), limit is 0 ``` ``` #[redline(latency = "< 1us")] fn too_slow() -> u64 { let mut sum: u64 = 0; for i in 0..10000 { sum += i; } sum } ``` ``` error: redline: estimated worst-case latency 10001ns exceeds bound 1000ns in `too_slow` ``` 二进制文件永远不会生成。性能违规会在任何代码运行之前被捕获。 ## 支持的约束条件 | 约束条件 | 语法 | 检查内容 | |-----------|--------|---------------| | Latency | `latency = "< 1ms"` | 最坏情况下的预计执行时间 | | Throughput | `throughput = "> 1GB/s"` | 最小持续吞吐量 | | Allocations | `allocs = 0` 或 `allocs = "< 5"` | 堆分配次数 | | Syscalls | `syscalls = 0` | 系统调用次数(I/O、网络、打印) | | Stack size | `max_stack = "< 4KB"` | 栈帧大小估计值 | ### 时间单位 `ns`, `us`, `ms`, `s` ### 存储容量单位 `B`, `KB`, `MB`, `GB`, `TB` ## 工作原理 Redline 是一个 Rust 的 proc-macro。在编译时,它会: 1. 解析性能标注 2. 遍历函数的 AST(抽象语法树) 3. 统计分配次数:`Vec::new`、`Box::new`、`String::from`、`.clone()`、`.collect()`、`.to_string()`、`.to_owned()`、HashMap/BTreeMap 等。 4. 统计系统调用次数:`fs::read`、`File::open`、`TcpStream::connect`、`println!` 等。 5. 估算循环成本:字面量范围(`0..1000`)提供精确的迭代次数,未知范围假设为 1000 次(悲观估计)。 6. 采用最坏情况分支:if/else 和 match 会分析所有分支,并报告较慢的那一个。 7. 汇总成本模型并与标注进行比较。 8. 如果违反了任何约束条件,则触发编译错误。 ## 成本模型 成本模型使用基于现代 x86-64 架构的保守估计: | 操作 | 预计成本 | |-----------|---------------| | ALU operation | 1 ns | | Branch | 1 ns | | Array index | 1 ns | | Function call | 5 ns | | HashMap lookup | 25 ns | | Heap allocation | 50 ns | | HashMap insert | 50 ns | | Mutex lock | 100 ns | | String format | 200 ns | | Syscall (file I/O) | 1,000 ns | | println! | 5,000 ns | | Network syscall | 10,000 ns | 这些值故意设定得非常悲观。拒绝一个快速的函数也比接受一个慢速的函数要好。 ## 功能限制 - 不会在 runtime 进行 profile。所有分析均在编译时完成。 - 不保证精确到纳秒的准确性。成本模型只是一种估计。 - 不进行跨函数边界的分析(被调用者的成本不会被内联)。 - 不具备感知 runtime 值的能力。若要进行精确分析,循环边界必须是字面量;对于变量则按最坏情况(1000 次迭代)进行假设。 - 不能替代基准测试。请使用 Redline 来设定硬性边界,使用 criterion 进行实际测量。 ## 架构 ``` src/ lib.rs Proc-macro entry point (#[redline(...)]) parse.rs Attribute parser (latency, throughput, allocs, syscalls, max_stack) analyze.rs AST walker: counts allocs, syscalls, estimates latency per path cost.rs Cost model constants and recognized function signatures ``` ## 相关技术 目前没有其他工具能做到这一点。相近领域的工具包括: | 工具 | 功能 | Redline 的不同之处 | |------|-------------|-------------------| | **Clippy** | Linting(代码风格、常见错误) | Redline 强制执行性能边界,而非代码风格 | | **Miri** | runtime 检测未定义行为 (UB) | Redline 在编译时工作,而非 runtime | | **Criterion** | 基准测试 | Redline 提供保证,而非测量 | | **perf/flamegraph** | runtime 性能分析 | Redline 阻止慢速代码通过编译 | | **WCET analyzers** | 最坏情况执行时间分析(嵌入式/实时系统) | 这些工具在二进制文件/IR 上运行,而 Redline 在源码 AST 上运行 | | **#[no_std]** | 移除标准库 | Redline 允许你使用 std,但会限制你的使用方式 | WCET(最坏情况执行时间)分析存在于嵌入式/航空电子领域,但它运行在编译后的二进制文件或 LLVM IR 上,需要特定硬件的计时模型,并且无法作为语言级别的标注使用。Redline 以 proc-macro 的形式将这一概念引入到了源码级别。 ## 路线图 **v0.1**(当前版本)- 具备分配计数、系统调用检测、基于循环边界和操作成本的延迟估算功能的 Proc-macro。包含 10 个编译时测试用例。 **v0.2** - 跨函数分析(内联被调用者的成本)。缓存感知成本模型。I/O 成本建模。集成 LLVM 成本模型以进行指令级别的估算。 **v0.3** - runtime 验证模式:对编译后的代码进行插桩,以验证静态分析结果。建立反馈循环,根据真实硬件校准成本模型。 ## 文档 - [Wiki:快速入门](docs/wiki/Quick-Start.md) - [Wiki:约束条件参考](docs/wiki/Constraints.md) - [Wiki:成本模型](docs/wiki/Cost-Model.md) - [Wiki:用例](docs/wiki/Use-Cases.md)(6 个真实场景) - [Wiki:局限性](docs/wiki/Limitations.md)(坦诚说明无法捕获的内容) - [Wiki:架构](docs/wiki/Architecture.md) - [Wiki:故障排除](docs/wiki/Troubleshooting.md) ## 许可证 Apache-2.0 | ALIA Labs 由 ALIA Labs 的 [Tushar Sharma](https://github.com/TxsharDev) 构建。标签:Rust, SOC Prime, 云安全监控, 可视化界面, 宏, 开发工具, 性能分析, 编译期检查, 网络流量审计, 通知系统, 静态分析