REA 中的 Java vs Rust Ghidra：來自進行中的 Rust 移植的早期基準測試

I’m working on rea-rust , a Rust port of REA , a local reverse-engineering tool. This is still a work in progress. Compatibility, analysis coverage and output readability are active areas of development. These benchmarks show what worked and where the tested build still needed improvement. I compared the TypeScript version’s Java Ghidra backend with the native version’s Rust Ghidra backend. For a small C program , these were the median results from seven fresh sessions on an M1 Pro Mac: What I measured TypeScript + Java Ghidra Native + Rust Ghidra Start the tool and get the first decompiled function 9.43 seconds 0.39 seconds Request a function after analysis is ready 16 milliseconds 15 milliseconds Sampled peak memory, including child processes 1,022 MiB 214 MiB The biggest improvement was startup. Once analysis was ready, the first decompilation request took about the same time. The larger Go test exposed a compatibility problem. Java returned all three requested functions. Rust returned none because of a duplicate import name. That failure is included in the report. Java also produced more readable output in the C example, showing strings and variable names where Rust sometimes showed memory addresses. These gaps are part of the ongoing work. The backends use different Ghidra engine versions and analysis implementations. Results from one Mac and these targets don’t establish equivalent analysis quality or general performance. The Rust backend uses the existing ghidra-decompiler crate. Development and benchmark tooling were AI-assisted. Full Ghidra report, scripts, raw results and limitations . Reproducing the exact tested builds still requires the original local source snapshots. Which public binaries and analysis tasks would you suggest testing next? submitted by /u/nanashili to r/LovingOpenSourceAI [link] [comments]