# EPF5 Week 19 Update

It works!!! I've successfuly written and debugged every component of my project. Preliminary tests on beacon block decoding shows a roughly 60% speedup, and encoding shows 75% to 89% speedup.

---

I ran a quick benchmark on `SignedBeaconBlock` encoding + decoding:


Unfortunately due to some trait quirks in milhouse, I had to use `VariableList` and `FixedVector` from [ssz_type](https://github.com/sigp/ssz_types) to implement the `SignedBeaconBlock` type. This means I had to compare to a lighthouse implementation that used those types instead of milhouse types, which would be more representative of real world conditions.

Here's how lighthouse's `ethereum_ssz` compares:


Looking pretty good just off the initial tests. These don't use the same types that are running in production lighthouse right now, but they are comparable for evaluating sszb (my crate) vs lighthouse.

This is how lighthouse beacon block decoding fares with milhouse types:


I'd say Grandine still has an edge though, which is clearly seen in the encoding performance. I'd argue that the slower decoding performance isn't representative of being slower than sszb since Grandine uses their own persistent list type which is supposed to be slow. Slower performance is expected, so we still need to see how sszb fares when decoding persistent lists.


Luckily I still have a few tricks up my sleeve to give sszb even more of an edge:

- Efficient error handling
- Using [`Buf.take`](https://docs.rs/bytes/latest/bytes/buf/trait.Buf.html#method.take) and [`Buf.limit`](https://docs.rs/bytes/latest/bytes/buf/trait.BufMut.html#method.limit) for idiomatic bounds checks, which should help the compiler make optimizations to our assembly
- *Inlining*. Grandine's ssz implementation is full of inlining, which we haven't used yet. I'm hoping for a [Rock Lee moment](https://www.youtube.com/watch?v=o47N_90sC5k) once I bust out the inlines.