Skip to content

gh-160735: Fix Gecko marker end times during binary replay - #160738

Open
ivonastojanovic wants to merge 1 commit into
python:mainfrom
ivonastojanovic:gecko-replay-end-time
Open

ivonastojanovic wants to merge 1 commit into
python:mainfrom
ivonastojanovic:gecko-replay-end-time

Conversation

@ivonastojanovic

Copy link
Copy Markdown
Contributor

Binary replay can deliver sample batches from different threads out of timestamp order. GeckoCollector used the final timestamp from the most recent batch, which could close open markers before they started.

Keep the latest timestamp seen across all batches and calculate the sample interval when serializing the profile.

Binary replay can deliver sample batches from different threads out of
timestamp order. GeckoCollector used the final timestamp from the most
recent batch, which could close open markers before they started.

Keep the latest timestamp seen across all batches and calculate the sample
interval when serializing the profile.
@ivonastojanovic

Copy link
Copy Markdown
Contributor Author

@pablogsal I also noticed that when we replay a binary profile with several threads, the exported interval gets divided by the thread count (4 threads at 1 ms show up as ~0.25 ms). Live sampling is fine since it gets all threads in one collect() call, but replay calls it once per thread batch. Gecko itself just writes the configured sampling interval there. Is this something we care about?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant