Remove debug feature from fuel-vm and use debugger by default.
#554
Conversation
There was a problem hiding this comment.
What is the motivation behind this change? On one hand, I can see that it could simplify our builds if we don't need to distinguish between a debug and release build. On the other hand, it seems a bit unorthodox to mix debug features in as an always-compiled runtime check.
| /// Single-stepping mode triggers a breakpoint after each instruction | ||
| single_stepping: bool, | ||
| breakpoints: HashMap<ContractId, HashSet<Word>>, | ||
| last_state: Option<ProgramState>, | ||
| } | ||
|
|
||
| impl Debugger { | ||
| /// Returns `true` if the `Debugger` is active and used. | ||
| pub const fn is_active(&self) -> bool { |
There was a problem hiding this comment.
Would it be useful to expose an API to activate the debugger explicitly, without calling a set_* function?
There was a problem hiding this comment.
Is there any way to turn off debugging once it's on? In case you need to switch between debugging and performance modes
There was a problem hiding this comment.
We don't provide this kind of functionality on the API side, so we don't need to worry about on VM side right now. Plus, in the future, we plan to re-work how the debugger works, and it is more to support that already exists.
Co-authored-by: Brandon Vrooman <brandon.vrooman@fuel.sh>
If we don't want to produce two images( While the second solution doesn't impact performance, it causes a lot of modifications in the code, propagating generic everywhere. I decided to select the approach with the checking of one variable instead of a generic one to make the change fast. It shouldn't affect performance too much. If you prefer the way with generic, I can re-work it=) But I tried to avoid potential conflicts with #533 |
I think your approach is fine because the current set of debug features is small, generally doesn't branch (i.e. debug behaviour vs. production behaviour), and likely introduces only minimal performance impact. But this does mean that, going forward, we need to continue with this contract. If and when we continue to add debug features that are "always-compiled-but-sometimes-enabled", we may want to track performance for any degradations. |
No description provided.