Replies: 3 comments 2 replies
-
I think what I'd like resembles that: |
Beta Was this translation helpful? Give feedback.
-
Also would like to double down on the enthousiasm I share for this project, the state of rust debugging is globally bad, hard to setup etc and I think this is very promising ! |
Beta Was this translation helpful? Give feedback.
-
Thank you for starting a discussion. Replying to OP, #[firedbg(profile = "audio")] and so you can precisely filter which parts of the program to trace by selecting the right profile. But a big blocker for now is we don't have the static call-tree, so we can't intelligently filter the children. I think the most doable way is to fork and trim down rust analyzer to only do enough work to extract the static call-tree, and to dump that info to disk. |
Beta Was this translation helpful? Give feedback.
-
Hi! I'm really loving this project so far, and I hope I didn't just miss something in the documentation about this but:
I often use Rust for very high-performance real-time (e.g. game/graphics/audio stuff) applications, often multithreaded, which is of course difficult to debug. This project seems like it has the potential to make my life much much easier, but currently it seems to collect everything, which makes it infeasible to debug the kinds of applications I make, both due to the performance hit and the amount of data it collects.
Basically what I'm proposing is, would it be possible to make a macro/wrapper that can conditionally enable debugging for all child function calls? e.g. I don't want to slow down my graphics when debugging a single function in my audio system. And in the audio system, I don't want to slow down the whole audio system when I'm debugging one edge case with known inputs that cause it.
But yeah, looking forward to the future of this project!
Beta Was this translation helpful? Give feedback.
All reactions