| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
We use the fields in the profile state singleton.
|
| |
|
|
| |
We are going to re-use them in the profile CLI tool.
|
| |
|
|
|
|
|
| |
We want to have access to more metadata, including the application id,
when capturing profiling data for later review, as the immediate
association between a process and its profiling data is not available in
that case.
|
| |
|
|
|
| |
We only remove probes when unloading state, so we don't need to remove
the probe from the state itself.
|
| |
|
|
| |
Leftovers from an earlier iteration.
|
| |
|
|
|
|
| |
Always print out the number of samples and the total time, regardless of
the number of samples; in case we have more than one sample, be more
specific and add the average, minimum, maximum, and standard deviation.
|
| |
|
|
|
|
| |
We should only give up if we didn't have any samples.
https://phabricator.endlessm.com/T20769
|
|
|
The EosProfileProbe API allows defining profiling probes that can be
used to efficiently measure the time spent in a critical section.
The Profiling API is meant to collect samples and generate a report
at the end of the lifetime of the process, either by printing out the
results once the process terminates; or by saving the raw data in a
binary file that can be loaded at a later date.
This profiling API is meant to be as close as possible to a zero cost
abstraction:
- probes are only allocated if profiling is enabled
- all profiling API is a no-op if profiling isn't enabled
- the C API is meant to be easily tied to a scope, through the
use of auto-cleanup macros provided by GLib
This allows projects using the Endless SDK to keep the profiling probes
in place, instead of conditionally compile them in.
https://phabricator.endlessm.com/T18514
|
