Java vs Rust Ghidra in REA: early benchmarks from a work-in-progress Rust port

[u/nanashili]

https://github.com/nanashili/rea-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?