# EPF5 Week 16 Update

- added more features to ssz-arena, still have some pesky bugs to fix :/
- made some progress on the derive macros, which iis what this update is mostly about

---

## Trait Design is Slow, then Fast
Back in [Week 13 & 14](/nNYOPgZhQAyVe7ZbdFU8Jg), I wrote about trait design and the effect it can have on performance and DevEx.

I have since made some changes to the `SszEncode, SszDecode` traits to leverage the [`Buf`](https://docs.rs/bytes/latest/bytes/buf/trait.Buf.html#) trait.

pub trait SszEncode {
    // length functions ommitted

    fn ssz_write_fixed(&self, offset: &mut usize, buf: &mut impl BufMut);
    fn ssz_write_variable(&self, buf: &mut impl BufMut);

    fn ssz_write(&self, buf: &mut impl BufMut) {
        let offset = &mut Self::ssz_fixed_len();
        self.ssz_write_fixed(offset, buf);
        self.ssz_write_variable(buf);
    }
}

Types that implement `BufMut` can allow for reads with an auto-incrementing cursor. Notably, `[u8]` implements `BufMut`, which means we can continue to pass around slices for better performance while *abstracting away* all the offset accounting.

This simple change has a huge impact on the simplicity of the derive macro implementation, since we just need to make succesive calls to read (same applies for `SszDecode`) and write. No messing with offsets in our macro. This makes compilation times faster too since there's less code generation.

Rust prides itself on its *zero cost abstractions*, which is a fancy way of saying that using neat abstractions shouldn't come at any (performance) cost. The unknown here with the `BufMut` trait is whether that abstracted accounting is *actually* free. I'll need to wrap up the implementation (which is coming soon) so I can actually test this out.

It would be cool to see whether something as benign as trait design could have any significant effects on performance and code complexity. I could have started coding much sooner, but I was dissatisfied with the API I had come up with before. I will feel very vindicated if all that ~~stalling~~ thinking I did amounted to something.

## Be Direct
Direct access in SSZ has always been possible [in theory](https://epf.wiki/#/wiki/CL/SSZ) without fully deserializing the object, but no rust crate does it yet.

This may be useful in latency-critical scenarios, or even in scenarios where a field needs to deserialized sooner in the hotpath before the entire object gets decoded in the cold path.

I think it would be cool to ship this feature, I'm just not sure who would use this. I'm still asking around.