[Development] Qt PIM object ids: the price of being generic

[lars.knoll at nokia.com]

Hi Robin,

that's a nice analysis and it shows that it's worth thinking about the
data types we use in our APIs and implementations. In this case it's
probably as easy to use a QUuid as a QString or QByteArray, but the
performance difference is significant.

I've seen many other cases (and I'm guilty of some of them as well), where
we've been using rather generic data types (like QVariant) to implement
low level or performance critical parts in Qt. We should think twice about
what we do there, and especially how the APIs we expose tie us into
certain types.

Excellent performance is crucial and should come at the top of the list
when we thing about how we implement a piece of functionality and expose
it to other developers.

Cheers,
Lars


On 1/16/12 4:52 PM, "ext Robin Burchell" <robin+qt at viroteck.net> wrote:

>Hi Cristiano (& other interested PIM folks),
>
>Some months ago now, I raised the problem that QString wasn't an
>optimal data format for QContactLocalId in Qt 5
>(http://lists.qt-project.org/pipermail/development/2011-November/000164.ht
>ml).
>There was some consensus at the time, but things sort of tapered off
>until the recent change implementing one of the planned solutions:
>doing away with QContactLocalId altogether, and having contact IDs be
>engine-defined (http://codereview.qt-project.org/#change,13060).
>
>This in itself is a pretty sensible change, I mostly agree with it,
>and it matches what the Organizer API does, which is probably a Good
>Thing. There is still, however, the problem of using QString in unique
>identifiers for contacts (and for organizer items, presuming they use
>the exact same approach), and I do think that this is probably a
>mistake. After all, you really don't need unicode specifiers for what
>is essentially opaque data only of importance to the engine.
>QByteArray would probably do just as well.
>
>Using a blob of data does give you somewhat more 'portability' between
>backends, however, you may want to consider directly store a QUuid.
>Most contacts backends I have seen often have some form of unique
>identifier involved, and for those that don't, it wouldn't be
>impossible to provide a map of native engine ID to QUuid, similar to
>what was done with native engine ID <-> QContactLocalId (uint) back in
>Qt 4 times.
>
>I did some (admittedly overly simplistic, I was in a hurry)
>benchmarking of QString vs QByteArray vs QUuid, both memory overhead
>and performance (as in, time taken to copy). Code can be found at
>http://qtl.me/nBG.txt.
>
>Here's the results:
>
>tst_QtContacts_bench::tst_QtContacts_bench() Memory overhead of
>QList<1000 string UUIDs>:  108104
>tst_QtContacts_bench::tst_QtContacts_bench() Memory overhead of
>QList<1000 bytearray UUIDs>:  68152
>tst_QtContacts_bench::tst_QtContacts_bench() Memory overhead of
>QList<1000 RFC form UUIDs>:  44136
>tst_QtContacts_bench::tst_QtContacts_bench() Memory overhead of
>QList<1000 QUuid>:  28768
>
>********* Start testing of tst_QtContacts_bench *********
>Config: Using QTest library 5.0.0, Qt 5.0.0
>PASS   : tst_QtContacts_bench::initTestCase()
>RESULT : tst_QtContacts_bench::benchString():
>     0.00064 msecs per iteration (total: 85, iterations: 131072)
>PASS   : tst_QtContacts_bench::benchString()
>RESULT : tst_QtContacts_bench::benchBytearray():
>     0.00060 msecs per iteration (total: 79, iterations: 131072)
>PASS   : tst_QtContacts_bench::benchBytearray()
>RESULT : tst_QtContacts_bench::benchToRfc4122():
>     0.00033 msecs per iteration (total: 87, iterations: 262144)
>PASS   : tst_QtContacts_bench::benchToRfc4122()
>RESULT : tst_QtContacts_bench::benchRawUuid():
>     0.000091 msecs per iteration (total: 96, iterations: 1048576)
>PASS   : tst_QtContacts_bench::benchRawUuid()
>PASS   : tst_QtContacts_bench::cleanupTestCase()
>Totals: 6 passed, 0 failed, 0 skipped
>********* Finished testing of tst_QtContacts_bench *********
>
>This demonstrates that a list of QUuid has around a 70% decrease from
>using QString in required memory usage when storing lists of contacts
>IDs (not at all unusual for things like this), and would also be
>roughly an order of magnitude faster to copy individual IDs around.
>
>I hope that this helps demonstrate the point I'm trying to make for
>evaluating future work on PIM.
>
>BR,
>
>Robin
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development