The most important missing piece of documentation is the mental model for the API. Based on reading the code, the intended use is something like:
When an event that you are interested in starts, call Add with some unique identifier for the event. When an event stops, call Remove with the unique identifier. Calling WriteTo dumps all currently active events.
An example and perhaps a blog post showing a real life solved use case would be very helpful.
I also think that there are useful profiling-y use cases not well served by the current API/implementation. I will file a separate issue about that.
Custom profiles are under-documented.
The most important missing piece of documentation is the mental model for the API. Based on reading the code, the intended use is something like:
When an event that you are interested in starts, call Add with some unique identifier for the event. When an event stops, call Remove with the unique identifier. Calling WriteTo dumps all currently active events.
An example and perhaps a blog post showing a real life solved use case would be very helpful.
I also think that there are useful profiling-y use cases not well served by the current API/implementation. I will file a separate issue about that.
cc @matloob
The text was updated successfully, but these errors were encountered: