This ensures that simple to handle yet important queries are answered in a
timely manner. Previously an onslaught of slow symbol-related queries could
block e.g. zone name resolving for a couple of minutes.
In case of CPU statistics data, this entry is created during creation of a
source location. This won't be done for GPU zones, as it would needlessly
expand the number of held entries. This is assuming the number of GPU zones
is significantly less than the number of CPU zones.
Note: Zone counts are currently being calculated, but they are not being
saved. Proper usage of this data (as is performed in the CPU counterpart)
would remove the possibility of insertion of new entries into the map in
ReconstructZoneStatistics().
The disconnect handling logic is broken on the client, after the symbol
resolution was moved to a separate thread. Use workaround until a proper fix
is available.
In the default configuration this limit is unlikely to be hit. On Windows the
send buffer is 64 KB, which results in ~5K entries. On Linux the buffer is a
bit higher and the number of entries is lower than 7K.
Sorting samples during load was a major mistake, as three different background
processing threads were concurrently accessing the samples table, and it was
being sorted in one of them!
Context switch callstack samples are not included in the sampling data
statistics (as these don't represent random sampling), but are rather put into
a separate dedicated data structure.
For this to work, a complete context switch data has to be available for the
callstack timestamp. There is no guarantee it will be present at the time it
is needed, so a second structure is added to allow postponing qualification of
callstacks.
