---
title: "REA 中的 Java vs Rust Ghidra：来自进行中的 Rust 移植的早期基准测试"
url: "https://reamcp.dev/zh-cn/cases/java-vs-rust-ghidra-in-rea-early-benchmarks-from-a-work-in-p-a312b3"
source: "https://www.reddit.com/r/LovingOpenSourceAI/comments/1xe5r98/java_vs_rust_ghidra_in_rea_early_benchmarks_from"
source_type: "reddit"
author: "nanashili"
author_handle: "nanashili"
stars: 0
category: "工具与集成"
categories: ["tools-integrations"]
tags: ["benchmark", "decompiler", "ghidra", "port", "reverse-engineering", "rust"]
added: "2026-10-25T02:56:12.894Z"
updated: "2026-10-25T02:56:12.894Z"
locale: "zh-cn"
content_locale: "zh-cn"
---

# REA 中的 Java vs Rust Ghidra：来自进行中的 Rust 移植的早期基准测试

/u/nanashili 的 Reddit 帖子展示了 rea-rust 的早期基准测试，rea-rust 是 REA 的一个进行中的 Rust 移植，在一个小型 C 程序和一个较大的 Go 目标上，将 TypeScript 版本的 Java Ghidra 后端与原生 Rust Ghidra 后端进行比较。

## Description

作者报告了在一台 M1 Pro Mac 上七次全新会话的中位数结果：从启动到第一个反编译函数的耗时从 9.43 秒（TypeScript + Java Ghidra）降至 0.39 秒（原生 + Rust Ghidra），分析后的函数请求相当（16 毫秒 vs 15 毫秒），包含子进程在内的采样峰值内存从 1,022 MiB 降至 214 MiB。更大的 Go 测试暴露出一个兼容性问题：Java 返回了所有三个请求的函数，而 Rust 因重复的导入名称没有返回任何函数；在 C 示例中 Java 输出更可读（字符串和变量名 vs 内存地址）。作者指出，这些后端使用不同的 Ghidra 引擎版本和分析实现；来自一台 Mac 和这些目标的结果并不能确立同等的分析质量；Rust 后端使用现有的 ghidra-decompiler crate；开发和基准测试工具均得到 AI 辅助。文中引用了完整的 Ghidra 报告、脚本、原始结果和限制，但复现确切测试过的构建仍需要原始本地源代码快照。帖子最后询问接下来要测试哪些公开二进制文件和分析任务。

## Original README

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]