On 2014/10/07 15:13:22, Jakob wrote:
Alexei, Yury: I'd like to make this change for internal profiling purposes
(--prof + linux-tick-processor). For analyzing big
applications/benchmarks, it
can be helpful to know which C++ entry points (say, LoadIC_Miss,
Runtime_ArrayConcat, etc) were expensive in aggregate.
It appears that this CL as is would also affect the public sampling API,
as of
https://codereview.chromium.org/596533002. Do you have any suggestions
how to
modify the mechanism so the publicly exported information is unchanged? I
could
thread through a flag so when we're coming from Sampler::SampleStack(),
we'll
record the extra frame, and otherwise (CpuProfiler::StartProfiling() or
V8::GetStackSample()), we won't. Does that sound reasonable?
Or would you even prefer to specifically include these extra frames in
public
samples? Personally I think it doesn't make much sense, as such internal
details
are likely not interesting to JS developers.
Yes, that sounds absolutely reasonable to me, let's only record the extra
frame
when we are coming from TickSample::Init and skip it otherwise.
I don't think exposing C++ entry points would make much sense without
extending
public API that would allow the embedder to map C++ entry point -> function
name. The only way for the embedder to retrieve function name would be to
use
debug symbols I guess. I agree that most of the C++ entry points don't make
much
sense for JS developers and if we decide to expose them through the public
API
we should probably whitelist those that may be interesting for JS
developers.
https://codereview.chromium.org/638633002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
