On Tuesday 2 April 2024 07:35:19 PDT Lennart Poettering wrote:
> > This basically showed that CBOR is better in almost all benchmarks. So =
why
> > use JSON if you can use CBOR?
>=20
> Because it makes things *so* *much* *more* *debuggable*.
>=20
> If I use "strace" or some other debugging tool on a complex systemd
> session i can suddenly understand immediately what is going on,
> because I can directly make sense of every method call and every
> method reply becaus JSON is readable as tetx.

That depends on who's doing the debugging. I don't deny that it's harder to=
=20
read. If I strace the systemd-resolved transmission, I can immediately tell=
=20
what it is:

recvfrom(3, "{\"parameters\":{\"addresses\":[{\"ifindex\":4,\"family\":10,
\"address\":[32,1,72,96,72,96,0,0,0,0,0,0,0,0,136,68]},{\"ifindex\":4,
\"family\":10,\"address\":[32,1,72,96,72,96,0,0,0,0,0,0,0,0,136,136]}],
\"name\":\"dns.google\",\"flags\":1048577}}\0", 135152, MSG_DONTWAIT, NULL,=
=20
NULL) =3D 224

If it were binary, I might not know what it is.

But for anyone who's deeply involved with the project in question, they can=
=20
decode CBOR or D-Bus binary in their heads (I know I can).

> Sure, CBOR would make things a bit faster, but only a a couple of 10%
> or so (see zeeshan's numbers). That's not something I am too much
> concerned with. The debuggability is *a* *lot* *more* *important*.

I've posted why I am not completely convinced by those numbers. That's also=
=20
ignoring some other advantages, like the ability to use small integers for =
map=20
keys instead of (repeated) strings. Of the 224 bytes of the payload above, =
64=20
are the string keys. The 16 bytes of the IPv6 were transmitted in 39 bytes.

In the other email, you listed as a advantages:
> * Suitable to streaming large amount of data (i.e. useful for listing
>   larger directories of things, where the dbus broker would normally
>   kick you off the bus)
> * Defined behaviour for protocol upgrades (i.e. start with Varlink,
>   then clearly switch over to downloading blobs without varlink, on
>   the same connection)

With CBOR, you could do both without leaving the protocol and with minimal=
=20
overhead, because it *can* transmit binary, unlike JSON.

But I will agree with you that, given proper parsers, the cost of the conte=
xt-
switch and other inefficiencies will dwarf the parsing.

> (Also, JSON is what the web community generally uses, and Varlink is
> supposed to be easy, and natural to use via an HTTP proxy, i.e. it's
> request/response based, so if you glue a GET in fron of each method
> call and an HTTP 200 OK after each method reply you are basically
> already there.)

These days, one expects to start an SSL/TLS session, even for same-network=
=20
services, so if you're using a proxy, you'll use CONNECT.

On the other hand, if you're expecting to talk performance and minimal=20
resources, it would be the IoT community, not the web one, to talk to. The=
=20
IETF CoRE WG created CoAP, which is very similar to HTTP in semantics, but=
=20
simpler (think of it as an evolution of Google's QUIC, the same as CBOR bei=
ng=20
an evolution of MsgPack). And there you'd have UDP and DTLS.

> Round trips kill perfomance. Marshalling is much less
> expensive. Context switches are what today's CPUs are still shit
> at. Parsing streams of bytes is what they are really efficient at.
> hence, if you care about performance, look at the roundtrips =E2=80=93 the
> marshalling is just a minor factor.

=2D-=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering