Create sections encoding for multi-value regions

[webmaster128]

Closes #602

TL:DR:

• Before: value || key || keylen
• After: section1 || section1_len || section2 || section2_len || section3 || section3_len || …

It turned out that splitting the memory of a Vec into multiple vectors is heavility unsafe and it is better to keep the decoding in two steps:

1. consume Region into one vector using the exact raw components it was created with,
2. split the resulting vector into multiple values.

This means we need to do copies. If we split off from right to left, we can keep the original vector as the first element without reallocation, saving 50% of copies for the two element case.

[ethanfrey]

Ah, so the length after value is so we can parse from left-to-right.
Makes sense but definitely needs to be documented (also with the method names).

Will look at the code now

[ethanfrey]

Looks good.
Added some suggestions to polish

[ethanfrey]

Why not encode with 2 bytes as now?
We expect/support > 64KB passed as a value for each section?

Although I guess it is a trivial cost to support this and allows us to never worry about size

[webmaster128]

I'd rather not make unnecessary assumptions on data length.

[ethanfrey]

Can you pull this into a helper function (it is used twice)?
The less code that needs to change to go from decode_sections2 -> decode_sections3 -> decode_sectionsN the better

[ethanfrey]

Also, why not return error instead of panic?
Not that anyone would handle them, but panics don't provide any useful message to the caller, errors help debugging if something did go wrong in the vm side.

[webmaster128]

Because Rust's iterator interface does not support errors in next()

[ethanfrey]

🤦 Good point

[ethanfrey]

I was thinking of an lower-level api that would let one easily create decodeN wrappers.

split_tail(data: Vec<u8>) -> StdResult<(Vec<u8>, Vec<u8>)> which would parse out the last section, allocate memory and truncate the input return (head, tail).

one_element(data: Vec<u8>) -> StdResult<Vec<u8>> after splitting off all the N args, this is called for the last (first) item. It parses out the length bytes, ensures they are correct, and then returns the truncated input without a realloc.

We would end up with something like:

pub fn decode_sections2(mut data: Vec<u8>) -> StdResult<(Vec<u8>, Vec<u8>)> {
  let (head, second) = split_tail(data)?;
  let first = one_element(head)?;
  Ok((first, second))
}

pub fn decode_sections3(mut data: Vec<u8>) -> StdResult<(Vec<u8>, Vec<u8>)> {
  let (head, third) = split_tail(data)?;
  let (head, second) = split_tail(head)?;
  let first = one_element(head)?;
  Ok((first, second, third))
}

[ethanfrey]

This would make sense if we intend 3, 4, 5 variants and avoids any bugs in writing those. Not sure if we will ever need those however

[webmaster128]

This is pretty cool. Not because we need it not but because it explains the algorithm. Implemented. The caller code got even nicer:

pub fn decode_sections2(data: Vec<u8>) -> (Vec<u8>, Vec<u8>) {
    let (rest, second) = split_tail(data);
    let (_, first) = split_tail(rest);
    (first, second)
}

[ethanfrey]

Nice updates. Looking good

[ethanfrey]

and this is 0 alloc, right? so you don't even need to handle the head case differently and still just as efficient. nice.

[webmaster128]

Jupp. From Vec::new:

The vector will not allocate until elements are pushed onto it.

More general, a vector only allocates heap when capacity > 0.