search

cbor / cbor.github.io

cbor.io web site
74 stars 33 forks source link

Update impls.html #56

Closed rumpelsepp closed 4 years ago

rumpelsepp commented 4 years ago

Add https://github.com/fxamacker/cbor and remove incomplete implementation

cabo commented 4 years ago

So what is the state of 2tvenom's implementation?

rumpelsepp commented 4 years ago

According to github, it seems unmaintained for the last 2 years and has at least these known issues (from the readme):

cabo commented 4 years ago

According to github, it seems unmaintained for the last 2 years

Yes, I saw that. Is the other implementation you are referencing compatible (at least vaguely)? Or are they completely unrelated?

and has at least these known issues (from the readme):

  • Not support tags. 6 major type (in future)

Neither does the fxamacker one, AFACS.

  • Not support 16 floats encoding

OK

  • Not decode nil (null) vars

That is a limitation.

  • Encode does't support indefinite-length values.

Does the fxamacker one?

Just trying to find out if the 2tvenom one should stay in or is wholeheartedly replaced. Maybe I should contact 2tvenom.

rumpelsepp commented 4 years ago

Yes, I saw that. Is the other implementation you are referencing compatible (at least vaguely)?

Would say so. Same API design.

Does the fxamacker one?

I'll ask him.

fxamacker commented 4 years ago

Hi,

I maintain fxamacker/cbor. Thanks for considering it.

Not support tags. 6 major type

My decoder ignores tags but decodes tagged data. Encoder does not support tags yet.

Encode does't support indefinite-length values.

My decoder supports indefinite-length values for bytes/strings/arrays/maps. Encoder doesn't support it yet.

By comparison, 2tvenom/cbor doesn't appear to support decoding indefinite-length values, based on a quick look at 2tvenom/cbor/cbor.go.

Thanks again,

Faye

rumpelsepp commented 4 years ago

Encode does't support indefinite-length values.

Does the fxamacker one?

Since the last release it does.

https://github.com/fxamacker/cbor/releases/tag/v0.2.0

rumpelsepp commented 4 years ago

@cabo Do you expect me to change this pull request in any way? I am happy to incorporate any feedback.

fxamacker commented 4 years ago

I released fxamacker/cbor v1.0. Changes are summarized here.

Please let me know if you have any questions or suggestions. Thanks.

rumpelsepp commented 4 years ago

@cabo The mentioned cbor implementation evolved rapidly and is now in a state that I recommend adding to the website. The README now covers information to all limitations and there is a roadmap as well.

fxamacker commented 4 years ago

@cabo Hello! I released fxamacker/cbor 2.1. It is a fast, safe, and full-featured generic CBOR encoder and decoder in Go.

Compared to the best Go impl listed on cbor.io, it is more full-featured, faster, uses less memory, produces smaller data, and produces smaller apps (see comparisons below).

Please let me know if there's anything that's preventing fxamacker/cbor from being listed. I can provide a PR if you prefer not to replace an existing Go impl. Thanks!

fxamacker/cbor 2.1 supports:

More info at: Encoder and Decoder Options, and Standards

Here's how fxamacker/cbor compares to the best Go library currently listed on cbor.io using using test data from RFC 8392 A.1 for speed and memory comparisons.

Safety Comparison fxamacker/cbor 2.1 ugorji/go 1.1.7
Bad data 1 57.4 ns/op, 32 B/op, 1 allocs/op ⚠️ fatal error: out of memory
Bad data 2 67.7 ns/op, 32 B/op, 1 allocs/op ⚠️ runtime: out of memory: cannot allocate
Compiled Program Size Comparison fxamacker/cbor 2.1 ugorji/go 1.1.7
Custom app 2.7 MB 11.9 MB
cisco/senml 7.6 MB 12 MB
Speed Comparison (lower ns/op is better) fxamacker/cbor 2.1 ugorji/go 1.1.7
Encode CWT 457 ns/op 995 ns/op
Decode CWT 796 ns/op 1105 ns/op
Memory Comparison (lower numbers are better) fxamacker/cbor 2.1 ugorji/go 1.1.7
Encode CWT 176 B/op, 2 allocs/op 1424 B/op, 4 allocs/op
Decode CWT 176 B/op, 6 allocs/op 568 B/op, 6 allocs/op
cabo commented 4 years ago

Thank you for this interesting implementation, and apologies for my glacial speed merging the pointer to this.