GitLab

feat: take cbor adapters by-value when encoding

This just makes our lives easier when using them. We can now, e.g., pass
`CborInt(1)` to something that expects a `CBORMarshaler`.

fix: import "math" in generated code for uint8 unmarshalling

doc: document Write*EncodersToFile functions

fixes #51

feat: allow unmarshaling of struct with more fields than marshaled struct

chore: add a license file

fixes #47

fix: enforce maxlen in ReadByteArray()

use unix nanoseconds for encoding Cbortime

add a helper for roundtripping time.time objects

Add a validate function.

This function is equivalent to Deferred.UnmarshalCBOR, just more efficient
because it doesn't copy.

Fix import handling

Unfortunately, while goimports works in many cases, it won't always work. This
change handles imports internally.

Optimize discarding in ScanForLinks

Always allocate scratch space when marshalling into a map.

We use it for writing the keys.

This gives a pretty significant speedup and drops us down to an allocation per
link.

    name        old time/op    new time/op    delta
    LinkScan-4    4.03µs ± 3%    1.26µs ±12%  -68.79%  (p=0.000 n=10+10)

    name        old alloc/op   new alloc/op   delta
    LinkScan-4      881B ± 0%      112B ± 0%  -87.29%  (p=0.002 n=8+10)

    name        old allocs/op  new allocs/op  delta
    LinkScan-4      25.0 ± 0%       1.0 ± 0%  -96.00%  (p=0.000 n=10+10)

optimize byte reading

When using cbor-gen, we _usually_ work with byte buffers/readers. Calling
`ReadByte` on a byte.Reader/byte.Buffer is much faster than calling `Read` and
copying into a slice.

    name            old time/op    new time/op    delta
    Marshaling-4       911ns ± 2%     904ns ± 5%     ~     (p=0.646 n=9+10)
    Unmarshaling-4    4.46µs ± 1%    3.94µs ± 2%  -11.55%  (p=0.000 n=10+8)
    LinkScan-4        4.65µs ± 2%    4.01µs ± 2%  -13.76%  (p=0.000 n=9+10)
    Deferred-4        3.68µs ± 3%    3.02µs ± 4%  -17.91%  (p=0.000 n=10+10)

    name            old alloc/op   new alloc/op   delta
    Marshaling-4        160B ± 0%      160B ± 0%     ~     (all equal)
    Unmarshaling-4    3.46kB ± 0%    3.46kB ± 0%     ~     (all equal)
    LinkScan-4          880B ± 0%      880B ± 0%     ~     (p=0.650 n=10+10)
    Deferred-4         96.0B ± 0%     96.0B ± 0%     ~     (all equal)

    name            old allocs/op  new allocs/op  delta
    Marshaling-4        10.0 ± 0%      10.0 ± 0%     ~     (all equal)
    Unmarshaling-4      43.0 ± 0%      43.0 ± 0%     ~     (all equal)
    LinkScan-4          25.0 ± 0%      25.0 ± 0%     ~     (all equal)
    Deferred-4          3.00 ± 0%      3.00 ± 0%     ~     (all equal)

Optimize decoding

This way, we can't blow out our stack.

We use this quite frequently so it should be fast.

Note: this removes the depth restriction because the algorithm is no longer recursive.

Type asserting to a concrete type is ~10x faster than type asserting to an
interface. This change has a significant performance impact in my test. readByte
used to account for 10.8% of the time, now it accounts for 3.4%.

Buffering could lead to reading over the end of the object, corrupting the next object.

This patch also gets rid of "PeekByte" and uses the standard ReadByte/UnreadByte
interfaces. That way, we can avoid wrapping the byte reader in the happy path,
saving some overhead.

Fix named string issue

Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>

Signed-off-by: Jakub Sztandera <kubuxu@protocol.ai>