Open Arpafaucon opened 1 month ago
Report
I got back on the multiplexer work, trying to figure out the reason of the failure. What is still confusing is that the experimental profiler (as I read it) seems to want to consider all client-issued QueueItems
as answers to server queries.
handle_client_response
for the non-response frames partly fixes the issue, and i can now spawn the multpilexer with multiple clients. However, I have recurrent crashes to investigateget_time_and_field
that is needed to remap the time correctly (still have issues there), but I agree with cipharius: not a lot we can do without refactoring the profiler and/or the workerTracyEventDebug
, very nice to understand the protocol by example
This is not a bug report, but rather an attempt at documenting my work on #471.
I am still not experienced in the tracy code base, so I'd like to document a bit closely what I try, and what it gave.
What happened today
Worker
is a very central class that manages all the relevant data about a profiling runtracy
does a lot of internal data "compression"uint16_t
export-csv
gave me good insights on the important internal data structures ofWorker
import-chrome
on the other side shows how to feed data into aWorker
I tried testing #766 but I had no success so far, I get the error reported in https://github.com/wolfpld/tracy/pull/766#issuecomment-2203397281
To get my hands dirty, I explored an alternative approach that only supports offline files, let's call it
tracy-merge
.tracy-capture
processes)tracy-merge
on the set of generated*.tracy
, to generate one file that contains all the eventsWorker
. Basically I fill a big vector with events of all the profiling files in turn, taking care of re-mapping thread IDs to avoid overlapsCurrent result, generated from merging the same profiling run from
test/test_cpp
copied twice.