# EPF5 Week 7 Updates I didn't get the most done last week but I made up for it this week. I ran the included benchmarks on `fastssz` and `ssz15` (Peter's implementation). After visualizing their performance in a flamegraph it was clear that the `BeaconBlock` type took the most time to encode/decode. I also ran the benchmarks on the [lighthouse consensus types](https://github.com/sigp/lighthouse/blob/stable/consensus/types/benches/benches.rs) crate, which tested on `BeaconState` (from the consensus spec tests). I'm going to focus most of my testing on `BeaconBlock` and `BeaconState` since encoding/decoding these are likely bottlenecks. I managed to get real `SignedBeaconBlock` data from mainnet using `ethdo` that I then used to test encoding/decoding with [`ethereum_ssz`](https://crates.io/crates/ethereum_ssz) and [`ssz_types`](https://crates.io/crates/ssz_types). ### Findings I'll need to corroborate with others on these findings. - Decoding seems to take longer than encoding on `ssz15`, `lighthouse`, `ethereum_ssz/ssz_types`. - Performance is much better in the tests that use consensus spec tests instead of real data. This was expected. - Flamegraph isn't working on my `ssz_types` tests for some reason, will patch that soon. and some stats: ``` ssz_types (real data): SignedBeaconBlock decode: 354.26 µs SignedBeaconBlock encode: 238.48 µs SignedBeaconBlock roundtrip: 595.92 µs lighthouse (consensus spec test): BeaconState decode: 6.6846 ms BeaconState encode: 1.7705 ms ``` ### To Do - If decoding is usually longer than encoding, it would be interesting to see if there's any exceptions to the rule and find out why. Even case where decoding is disproportionately long would be interesting to look at. - Either change the ssz15 manual test to work with `SignedBeaconBlock` or get real `BeaconState` data. I should do the latter anyway so I'll go with that. - Go through the grandine ssz implementation and work on any low-hanging improvements to lighthouse's ssz crate. - Going to make enhancements where I can, and possibly push upstream - Working on this will inform whether upstream improvements are sufficient or if starting from scratch will be worthwhile