so, i have this vague generalization for the way we are doing cpu profiling, and sampling profiling:
sampling profiling: backend ie rbkit (in future) will send the whole call stack in fixed intervals. for better understanding, lets assume time difference between two samples is 1ns ie 1ns interval. in case of sampling profiling, we don't have to construct call stack, ie list of callers and callees the time which sample is taken, and it will be readily provided by backend.
cpu profiling implemented in rbkit: if we look at time granularity, least unit of measurement is nanosecond (lets ignore cpu ticks for now). by implementing virtual stack we can get list of callers and callees, so, the problem becomes very much similar to sampling profiling because we can determine call stack for each nano second.
if we separate virtual stack code to construct list of callers and callees, the code to display and interact with callgraph can be re-used in both the cases.
so, i have this vague generalization for the way we are doing cpu profiling, and sampling profiling:
sampling profiling: backend ie rbkit (in future) will send the whole call stack in fixed intervals. for better understanding, lets assume time difference between two samples is 1ns ie 1ns interval. in case of sampling profiling, we don't have to construct call stack, ie list of callers and callees the time which sample is taken, and it will be readily provided by backend.
cpu profiling implemented in rbkit: if we look at time granularity, least unit of measurement is nanosecond (lets ignore cpu ticks for now). by implementing virtual stack we can get list of callers and callees, so, the problem becomes very much similar to sampling profiling because we can determine call stack for each nano second.
if we separate virtual stack code to construct list of callers and callees, the code to display and interact with callgraph can be re-used in both the cases.