[Development] A faster qUtf8Printable for static trace points?
thiago.macieira at intel.com
Tue Sep 6 15:59:40 CEST 2016
Em segunda-feira, 5 de setembro de 2016, às 21:20:12 PDT, Milian Wolff
> Hey Thiago, others.
Is this what you were looking for me for on Sunday afternoon?
> bool QLibraryPrivate::load()
> TraceScope<...> ts(qUtf8Printable(fileName))
Hmm... I only agreed to something that has no runtime impact when not in use.
I thought the traces were totally out-of-line (recorded in a separate
section). Annotating variables sounds like a good idea, but annotating the
result of function calls... not so much.
> Trace points have nearly zero runtime overhead when not used . But the
> above has a super high cost due to calling QString::toUtf8, which constructs
> a temporary QByteArray and thus incurs a temporary runtime allocation. An
> alternative would be to use qUtf16Printable, which would be fast, but I
> fear it makes interoperability with existing trace point consumers hard.
> Can someone with experience on trace points confirm this assertion? If that
> is untrue, simply using qUtf16Printable above would make everything work,
> and be fast.
qUtf16Printable may reallocate if the QString in question was created with
fromRawData. But that's not a very common use-case. As for existing trace
point consumers, sorry, you're the expert. I have no clue if there are any
that dump UTF-16, but I wouldn't be surprised if there weren't. How hard would
it be to add them? Remeber that C++11 has char16_t.
> One way to handle the above case would be only doing the qUtf8Printable call
> when the trace point is enabled, but afaik that checking also is not done
> for free, and also makes the consumer code harder to write.
Right. Don't annotate with function calls. Annotate variables only. You can
mostly do this by adding an unreachable rvalue-ref overload, like qAsConst.
> Would something like this be acceptable for upstream? E.g. change
> qUtf8Printable to not allocate memory for up to PATH_MAX chars or similar,
> and otherwise fallback to the slow QByteArray (or simply truncate, which
> would be an option for trace points actually).
That change is interesting and we could accept it, but I still wouldn't want
it used in tracepoints. You avoid the allocation, but you're still converting
to UTF-8. Your benchmark doesn't show it because your strings are probably
very short and our UTF-8 algorithm is very optimised. It is dwarfed by the
No, instead the policy should be that we annotate only direct variables or
values that can be computed easily from the variable itself (like
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development