You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be amazing to have a companion crate, e.g. samply-markers, that one could add to their project as a dependency. This crate would expose an API where the programmer could create new markers directly in their code that are compatible the the Firefox Profiler.
The crate would be responsible for recording the markers and persisting them in such a way that samply can locate them and insert them into the resulting profile.json.
@gregtatum presented an interesting thought on the idea:
"Ok, here's an idea if I'm understanding mmap correctly, which I haven't ever used in practice myself. The user's program imports the marker Rust crate. The marker crate mmaps a file at some kind of known path. As it collects markers from the user program, it writes them into the mmaped space. I believe this will lazily be persisted to file so shouldn't cause a performance problem. When the user program exits, samply reads in that file and pulls out all the markers. Samply is then in charge of persisting that data into the profile JSON format and joining it to the sampled data."
The text was updated successfully, but these errors were encountered:
There's actually already support on mac/linux for parsing a marker-{pid}.txt file that a process opens, however the file format is extremely simple (literally "[time] [name]"), which is not good for anything but low frequency markers and doesn't support ranges. Needs some care to do things like define markers up front and then refer to them by ID + provide binary payload in the actual marker stream.
Background
This issue is inspired by this conversation in Mozilla's Firefox Profiler Matrix channel.
It would be amazing to have a companion crate, e.g.
samply-markers
, that one could add to their project as a dependency. This crate would expose an API where the programmer could create new markers directly in their code that are compatible the the Firefox Profiler.The crate would be responsible for recording the markers and persisting them in such a way that samply can locate them and insert them into the resulting
profile.json
.@gregtatum presented an interesting thought on the idea:
The text was updated successfully, but these errors were encountered: