D-Bus Versus Varlink

[Lennart Poettering]

On Do, 21.03.24 08:09, Thiago Macieira (thiago at kde.org) wrote:

> On Thursday, 21 March 2024 06:56:18 PDT Zeeshan Ali Khan wrote:
> > While I was a bit skeptical about the claim that JSON
> > encoding/decoding is only a small fish compared to the effects of
> > context switching, my own benchmarks convinced me that to be true:
> > https://toot.cat/@zeenix/111971114434573026
>
> This basically showed that CBOR is better in almost all benchmarks. So why use
> JSON if you can use CBOR?

Because it makes things *so* *much* *more* *debuggable*.

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.

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*.

(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.)

Note that the D-Bus is a bit slow because a call to system service
typically involves at least 10 messages, that kills everything
(i.e. client to broker, broker to service, service to broker to query
client creds, broker to service for te response, service to broker for
polkit, broker to polkit, polkit to broker, broker to service, service
to broker, broker to client). On Varlink that's severely cut down, in
particular if polkit one day would be accessible via varlink, too, in
which case it wouldbe 4.

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 – the
marshalling is just a minor factor.

> Also, suggestion for benchmarking: non-US-ASCII strings. I'm also not seeing
> any floating point numbers in your data. When you add those, add short and long
> strings and numbers (for example, pass 1e15 as "1000000000000000.000000").
> There's also a need for passing binary data, which JSON will require encoding
> as base64 and the encoding and decoding of that should be attributed to JSON,
> not the caller.

Yes, JSON sucks for 64bit integers. JSON-I suggests encoding them as
decimal strings, which I think is an OK approach.

Lennart

--
Lennart Poettering, Berlin