Performance considerations

[wasm-forge]

Hello,

I was wondering about the expected performance overheads when I am using the stable BTreeMap structure.

I wanted to split a buffer of 100Mb into small 4K chunks and store those in the stable map. The performance changes radically when I try to store directly into virtual stable memory vs using the BTreeMap. I've tried three methods:

1. (method store_memory) Store 100Mb into memory using memory.write, costs: 124_417_565 instructions
2. (method store_buffer) Store 100Mb as a single element into the BTreeMap, costs: 924_560_255 instructions (9x slower that direct write)
3. (method store_chunks) Store 100Mb as 4K blocks into the BTreeMap, costs: 10_231_263_653 instructions (100x slower than direct write)

I was wondering if this is reasonable overhead that we have.

You can check out the branch for testing: https://github.com/wasm-forge/treemap_chunks

Regards,
Stan

[dsarlis]

Hi Stan,

What you describe is indeed expected, i.e. a direct write into stable memory will have less overhead than using a StableBTreeMap. We have also had other people reporting an overhead between 10x - 100x as you report in your benchmarks, depending on the exact workload and access pattern.

There are some technical details involved around the design and implementation of the StableBTreeMap that explains some of this. We have some ideas on how this can be improved, e.g. the current theory is that the majority of time is spent navigating through the nodes of the BTreeMap which at the moment involves deserializing the keys stored to be able to navigate for every single access (and every node you go through). This is certainly not super efficient and we believe that with some caching of the node keys on the heap we can reduce this overhead a lot.

I don't have a precise timeline to share with you on when we will be able to address this but it's the next item on the list for stable structures work. It's also becoming important as other folks trying to use the stable structures will likely observe this overhead, so we will definitely prioritize in the short/medium term.

[ufoscout]

@dsarlis Is there any progress on this? Is there anything we could do to help with this issue?