@cuviper the new deserialization code in spite of working correctly, introduced some exploits related with OOM errors. I'm inclined to rollback to Vec's borsh deserialization code, considering the gains in performance of the new approach are very minute anyway, and their deserialization code already solves the problem at hand. lmk what you think

introduced some exploits related with OOM errors.

Please explain this! If there's an "exploit" footgun here, it needs to be commented at the very least.

@cuviper hm the problem is this deserialization code I wrote is blindly allocating a buffer for incoming items from a stream. the deserialization code in borsh for collections already guards against OOM related issues by limiting the size of allocations (possibly why it's occasionally slower in the benches I ran).

I'll revert the deserialization code to use Vec::deserialize_from_reader as I had before

Oh, I see -- I should really add limits to serde size_hint() deserializers as well, as they do in their own impls.

Your branch is not open to maintainer pushes, so I put suggested changes in my fork:
namada-net/indexmap@heliax/borsh-support...cuviper:indexmap:borsh-support

@cuviper thanks for the patches! I've included them in this branch

rebased on 2.2.4

This has been published in 2.2.5!

sweet. thanks!