On 07/24/2017 02:07 PM, Lluís Vilanova wrote:
> Vladimir Sementsov-Ogievskiy writes:
>
>> 21.07.2017 20:04, Lluís Vilanova wrote:
>>> Vladimir Sementsov-Ogievskiy writes:
>>>
>>>> Current trace system have a drawback: parameters of trace functions
>>>> are calculated even if corresponding tracepoint is disabled. Also, it
>>>> looks like trace function are not actually inlined by compiler (at
>>>> least for me).
>>>> Here is a fix proposal: move from function call to macros. Patch 02
>>>> is an example, of how to reduce extra calculations with help of
>>>> patch 01.
>>> The tracing functions *were* inlined last time I checked, although things
>>> changed quite a lot since then. Not sure that will make a lot of difference
>>> in
>>> terms of overall performance (needs measuring).
>>>
>>> As for arguments, each trace event has a define TRACE_{NAME}_ENABLED that
>>> you
>>> can use for that purpose. If this is not explained in tracing.txt, that is a
>>> documentation bug.
>> These macroses are about enable/disable traces statically. I'm saying about
>> dynamic disable/enable.
> Aha, I see. I think most events get passed already-calculated variables
> (usually
> for other purposes), so I don't think it will have much of a performance
> impact. Did you measure it?
>
>
> Thanks,
> Lluis
The idea is that we can add more complex stuff after the patch.
QMP command log is a very good example of that.
Actually at our opinion macro will be safe but much better
from the point of side-effects - arguments will never be evaluated
until the trace happened.
Den
