This saves us a non-inlineable function call. Thread local block is
accessed anyway, since we need to get the token, so we already have the
pointer and don't need to get it a second time (which is done inside
Windows' GetCurrentThreadId()). We also don't need to store the thread
id in ScopedZone anymore, as it was a micro-optimization to save us the
second GetThreadHandle() call.
This change has a measurable effect of reducing enqueue time from ~10 to
~8 ns.
A further optimization would be to completely skip thread handle
retrieval during zone capture and do it instead on retrieval of data
from the queue. Since each thread has its own producer ("token"), the
thread handle should be accessible during the dequeue operation. This is
a much more invasive change, that would require a) modification of the
queue, b) additional processing of dequeued data to inject the thread
handle.
Long-lived zones could send their end events without begin events in a
following scenario:
1. On-demand connection is made.
2. Zone begin is emitted, m_active is set to true.
3. Connection is terminated.
4. A new connection is made.
5. Zone end is emitted, because m_active is true.
To this point it was assumed that all zone end events will happen before
a new connection is made, but it's not necessarily true.
There shouldn't be any changes in generated code on modern
architectures, as the memcpy will be reduced to a store/load operation
identical to the one generated with plain struct member access.
GetTime( cpu ) needs special handling, as the MSVC intrinsic for rdtscp
can't store cpu identifier in a register. Using intermediate variable
would cause store to stack, read from stack, store to the destination
address. Since rdtscp is only available on x86, which handles unaligned
stores without any problems, we can have one place with direct struct
member access.
Since reply order is the same as the query order, the server already
knows what source location it receives. This observation allows placing
zone name into the source location struct.
Source file, function name and line number are now stored in a const
static container object. This has the following benefits:
- Slightly lighter profiling workload (3 instructions less).
- Profiling queue event size is significantly reduced, by 12 bytes. This
has an effect on all queue event types.
- Source location grouping has now no cost, as it's performed at the
compilation stage. This allows simplification of server code.
The downside is that the full source location resolution is now
performed in two steps, as the server has to query both source location
container and strings contained within. This has almost no real impact
on profiler operation.
