[Cbor] Re: Early allocation for packed CBOR (Re: Reminder: CBOR WG Virtual Meeting on 2024-12-11)

[Vadim Goncharov <[e-mail]>]

On Wed, 11 Dec 2024 16:19:29 +0100
Marco Tiloca <marco.tiloca=[e-mail]> wrote:

> Hi all,
> 
> Personally, I don't have an issue with the idea of (early) allocating 
> such a large number of tags per se.
> 
> We are not running out of tag numbers, and even consuming one fourth

We are running out of them (and simple values) in 0..23 range, for no
real benefit.

> of the remaining precious 1+1 tag numbers is in my opinion worth the 
> achieved compression result (as Carsten's exercise also showed in his 
> previous mail).

The problem is that cbor-packed does not achieve good compression at all.
For 2017's CBOR source of 1210 bytes, tag 25/256 method achieves 904
bytes (note it's forced for 3 bytes per even shortest reference, in
contrast to cbor-packed cheating with single byte) and cbor-packed
claims 793 for same method and 564 with prefixes - while even
limited LZF achieves 425..435 bytes (depends on key order) and less
limited LZ4 variants get 404..416 bytes.

I'll try to manually compress with my CBAR idea tomorrow.

Have we ever seen *real* benchmarks for cbor-packed? It seems the whole
proposal should be withdrawn.

> I also don't perceive the fundamental construct of packed CBOR as an 
> abuse of the tag concept.

But, given the context, it clearly is.

-- 
WBR, @nuclight