Add script to check block composition #131
Conversation
|
❌ Code is not formatted! Please run |
…rknet-replay into organize_bench_exec_data
FrancoGiachetta
requested review from
edg-l,
igaray,
azteca1998,
fmoletta,
pefontana and
gabrielbosio
as code owners
There was a problem hiding this comment.
Hi @FrancoGiachetta! I left you some comments we can discuss. Let me know what you think.
Also, can you add some documentation of this feature in the README?
replay/src/block_composition.rs
Outdated
| type BlockExecutionInfo = Vec<( | ||
| u64, | ||
| String, | ||
| Vec<Result<TransactionExecutionInfo, TransactionExecutionError>>, | ||
| )>; |
There was a problem hiding this comment.
What is the meaning of the u64 and the string? I think it would be better to declare a struct with named field:
struct BlockExecutionInfo {
block_number: u64,
timestamp?: String,
transactions: Vec<...>
}There was a problem hiding this comment.
It was for simplicity, since it just acts as a holder I didn't think it was worth to create another struct.
replay/src/block_composition.rs
Outdated
| #[derive(Debug, Serialize)] | ||
| struct BlockEntryPoints { | ||
| block_number: u64, | ||
| block_timestamp: String, | ||
| entrypoints: Vec<HashMap<String, Vec<EntryPointExecution>>>, | ||
| } | ||
|
|
||
| #[derive(Debug, Serialize)] | ||
| struct EntryPointExecution { | ||
| class_hash: ClassHash, | ||
| selector: EntryPointSelector, | ||
| } |
There was a problem hiding this comment.
If we aim for re-usability of the data, I think it's better to save the execution trace as a tree, rather than a flattened list. That way we have that information if we ever need it, and if you need it as a vector you can easily flatten it later.
There was a problem hiding this comment.
I don't quite understand what would be the benefit of using a tree instead of a vector in this case.
replay/src/block_composition.rs
Outdated
| if let Some(call) = execution.validate_call_info { | ||
| tx_execution.insert( | ||
| "validate_call_info".to_string(), | ||
| get_inner_class_executions(call), | ||
| ); | ||
| } | ||
| if let Some(call) = execution.execute_call_info { | ||
| tx_execution.insert( | ||
| "execute_call_info".to_string(), | ||
| get_inner_class_executions(call), | ||
| ); | ||
| } | ||
| if let Some(call) = execution.fee_transfer_call_info { | ||
| tx_execution.insert( | ||
| "fee_transfer_call_info".to_string(), | ||
| get_inner_class_executions(call), | ||
| ); | ||
| } |
There was a problem hiding this comment.
If you only ever save these three values in the Hashmap (validate_call_info, execute_call_info, fee_transfer_call_info), I think its better to define a new struct (i.e: TransactionEntryPoints) with those fields, instead of using a generic HashMap.
There was a problem hiding this comment.
I'll do that then
This PR adds a script that checks the average tx, transfers and swap an average block has (separated by the day of its execution) and generates a plot which also aggregates this information by day. It also adds a new command which executes a block range, collecting every entrypoint in
block_composition/<block_execution_range_name>.json. Every .json generated is a range of execution, we can have separated block ranges executing. Then, the script will loop through the files inside the folder and process all of them at once.To be able to run the script first you need to collect some data:
Then you run the script:
PD: by deafult <path_to_block_info> is block_composition