Performance Degradation with flutter_rust_bridge_codegen in Complex Projects

[kotepillar]

Description:
I’m experiencing very slow performance when using flutter_rust_bridge_codegen in a more complex Flutter/Rust project. Specifically, when I run:

flutter_rust_bridge_codegen generate --watch

the process takes a very long time to complete. Below is an example log:

Watching file changes on /home/my_app/rust/src...
[73.3s] Parse
  └── [73.3s] Cargo expand & syn parse
  └── [0.0s] Parse HIR
  └── [0.0s] Parse MIR
[0.0s] Generate
[2.0s] Polish
  └── [1.2s] Run Dart fix
  └── [0.8s] Run Dart formatter
  └── [0.1s] Run Rust formatter
  └── [0.0s] Auto upgrade

Notably, the parsing step alone takes more than 70 seconds, which severely impacts productivity.

Additionally, this performance issue appears to affect my IDE’s Rust analysis too (e.g., rust-analyzer in VS Code). Even detecting a simple function name typo can take a very long time to register.

Is this behavior a known limitation or a common issue when the project is large/complex?
Are there any suggested optimizations or configurations to improve code generation and analysis speed?
I’m happy to provide more details about my project setup and configuration if needed.

[welcome]

Hi! Thanks for opening your first issue here! 😄

[fzyzcjy]

Hmm, "Cargo expand & syn parse" phase executes cargo expand and syn's parse. Thus it may not be possible for frb to optimize it :(

Are there any suggested optimizations or configurations to improve code generation and analysis speed?

Brainstorms:

• Split the project: make the frb-related code in a small crate, and other code in another (big) crate.
• Do not use --watch, but only generate when there are changes that you know will affect the API

Additionally, this performance issue appears to affect my IDE’s Rust analysis too (e.g., rust-analyzer in VS Code). Even detecting a simple function name typo can take a very long time to register.

Not sure, just random guess: is it possible to be caused by cargo expand somehow hold some global lock on codebase? Or maybe the cargo expand takes cpu? Maybe need some experiment to dig more if needed.

[kotepillar]

@fzyzcjy Thank you for the quick response. My project schedule is quite tight at the moment, so I’ll need to hold off on deeper testing and feedback for now. Once I have time to explore your suggestions and see how they might help, I’ll let you know. Thanks again!

[fzyzcjy]

You are welcome! Feel free to ping me if there are any further questions/experiments.