Post by Julien Cugnière Post by Thiago Macieira Post by Konstantin Tokarev
If your serialized data is intended to be read by Qt applications only,
QDataStream may be a good choice
Binary QJsonDocument is the fastest, followed closely by QCborValue (new in
Out of curiosity, what makes QDataStream slow? From your other comment
on QBuffer, it sounds like it might be related to the QIODevice
interface. Does that mean it's impossible to get best performance
through QIODevice, because of some design flaw? Or is there something
else that makes QDataStream and QBuffer slow?
I benchmarked the full result, but didn't investigate what makes QDataStream
slow. But it suffers from the same problem that QXmlStreamWriter does: it uses
a QBuffer to write to a QDataStream (see  and ). QCborStreamWriter does
the same, actually -- I've only fixed QCborStreamReader to bypass it.
QDataStream's format is also quite big, storing all QStrings as UTF-16 with a
4-byte length prefix. So "Hello World" takes 4 + 2*11 = 26 bytes, whereas in
CBOR it takes 1 + 11. The larger format could mean we reallocate more often
and that causes delays.
Another issue is that QDataStream tries to store all integers in big endian,
unless you tell it otherwise. Since most machines are little-endian, that's a
waste of CPU cycles, as you're doing the endian conversion twice, for little
gain, however fast it is.
Finally, yes, QIODevice is not designed for performance. It's quite slow and
there's little we can do about it. There have been a lot of behind-the-scenes
improvements, by way of smarter buffering and sharing of more code between the
main QIODevice classes (QFile, QProcess, QTcpSocket, QNetworkReply
implementations). QBuffer is usually forgotten in that. Still, the main
problem is QIODevice's *design* and we're unable to change it.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center