[Development] State of "binary JSON" in 5.15+?

Thiago Macieira thiago.macieira at intel.com
Thu Apr 15 21:15:36 CEST 2021


On Thursday, 15 April 2021 07:36:08 PDT Stottlemyer, Brett (B.S.) wrote:
> On 4/14/21, 12:53 AM, "Development on behalf of Thiago Macieira"
> <development-bounces at qt-project.org on behalf of thiago.macieira at intel.com>
> wrote:
 
>     No, that was it. I assume you're caching templates which you need to
> modify slightly for each reply, not plain-text JSON.
> 
> Ahh, no.  Sorry for not being clear.  I'm the consumer of the REST API, not
> the producer.

This made it even less clear.

I was trying to draw the distinction between prepared JSON in a QString or 
QByteArray and a template that you needed to fill in. For example, suppose you 
need to send a POST with JSON data but you need to fill in some information in 
that POST before sending, such as a URI or an ID.

Because if the contents don't change, there's no need to use QJsonDocument, 
binary or not, to cache the request or reply. You can do that in QString or 
QByteArray form.

>     In Qt 5, the existing methods in QJsonDocument continue to work like
> they have done since 5.0.
> 
> I think you are saying this with a different use-case in mind, and I'd like
> to understand your use-case.  For my use-case, I disagree with your
> statement. Qt 5.14 could memcpy and cast a QByteArray into a QJsonDocument
> (untested, but by inspection of the Woboq code and the documentation saying
> binary JSON was "fast for mmap").  Qt 5.15 can't, although the
> fromBinaryJson API is still supported.

The in-memory format of QJsonDocument and related classes has indeed changed. 
But from your point of view that's not relevant. If you cache the prepared 
template in the form of a QJsonDocument, the behaviour and performance should 
be the same in either 5.14 or 5.15.

But that also means there's no reason to talk about the binary format any 
more. It's not a caching technique.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering





More information about the Development mailing list