-
Notifications
You must be signed in to change notification settings - Fork 357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add trace
functionality
#1642
Add trace
functionality
#1642
Conversation
be1079b
to
491e04f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the difference between debug and trace here?
The timestamp information. We can conflate the two things into one, but I think having two different calls makes sense / is more flexible. |
491e04f
to
3eacb86
Compare
Are there plans to merge this? Any feedback on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, Mauro. I did not look into your two PRs yet.
I think the change makes sense in general. However, given how under-utilized debug
is today, I am hesitant to add a new entry point.
What if we make the functionality available in the debug
import implementation? I wanted to improve the flexibility of that already. Basically it would be cool if do_debug
has a default implementation and also could be improved. println!("{}", msg);
is not goo enough for most mid-level cases.
We can add microsecond timestamps in RFC-3339 format my default there:
println!("[2020-12-15T10:57:26.778923Z]: {}", msg);
.
Sounds good. I'll do the proposed changes to Do you think this can be kept always on? The lack of default arguments in Rust makes it difficult to do this in a non-breaking way. In that sense, if we want to be able to enable / disable this functionality, a different entry point is better (less breaking) than adding a parameter to an existing one. The same with the proposed consumed gas print functionality (#1643). |
Perhaps we can implement a parametrised |
3eacb86
to
69d16ba
Compare
I'm thinking roughly of a solution like this is MockQuerier:
with a default value
that can be overriden:
If we have that available in With something like Rc instead of Box it should be possible to implement clone. Ideally the function is optional. If |
Not sure I understand. The original idea / proposal is having debug with timestamps and gas consumption, for real (non-mocked) environments. This allows you to print out timestamps and gas consumption in a node running with Update: Oh, you mean like the custom querier impl, but for debug. Let's discuss in chat how to do this in detail. |
Oh, yeah, the like is important here. See #1667 |
Closed in favour of #1667. |
Related to #746.
Useful for comparing wall time between contract code and blockchain code. This way the latency of the Go -> Rust and Rust -> Go bridges can be easily measured (and eventually improved).
Useful as well for general benchmarks of code and procedures. Elapsed time can be computed post-facto by subtracting calls to
trace()
.The performance of code between the native and wasm runtimes cannot be compared fairly, as the WebAssembly code is running inside the VM. But time measurements are useful as a relative reference for comparing different routines and implementations in contract code.
It could also be interesting to know how much faster native code is for particular tasks, compared to wasm code.