[Development] A faster qUtf8Printable for static trace points?

[Thiago Macieira]

Em segunda-feira, 5 de setembro de 2016, às 21:20:12 PDT, Milian Wolff 
escreveu:
> Hey Thiago, others.

Hey Milian

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 [1]. 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.

> https://github.com/milianw/bench_qt/blob/master/bench_qstring/
> bench_qstring.cpp#L118
> 
> 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 
memory allocation.

No, instead the policy should be that we annotate only direct variables or 
values that can be computed easily from the variable itself (like 
constData()).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center