Simplify sampling rate calculation

Simplify sampling rate calculation

Sampling rate is now calculated as total number of samples divided by profiling time in ms. Before the patch the sampling rate was updated once per 100ms which doesn't have any obvious advantage over the simpler method.

Also we are going to get rid of the profile node self and total time calculation in the v8 CPU profiler and only expose profiling start/end time for CpuProfile and number of ticks on each ProfileNode and let clients do all the math should they need it.

BUG=None
R=bmeurer@chromium.org, loislo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=15944

[loislo, 2013-07-29 18:01:27]

lgtm

https://codereview.chromium.org/21105003/diff/1/src/profile-generator.cc
File src/profile-generator.cc (right):

https://codereview.chromium.org/21105003/diff/1/src/profile-generator.cc#newc...
src/profile-generator.cc:379: start_time_ms_(OS::TimeCurrentMillis()),
Can we do that on the first sample?

[yurys, 2013-07-29 18:13:21]

https://codereview.chromium.org/21105003/diff/1/src/profile-generator.cc
File src/profile-generator.cc (right):

https://codereview.chromium.org/21105003/diff/1/src/profile-generator.cc#newc...
src/profile-generator.cc:379: start_time_ms_(OS::TimeCurrentMillis()),
On 2013/07/29 18:01:27, loislo wrote:
> Can we do that on the first sample?

Doing it here should be more fair. With the sampling being done on the
processing thread it will make no difference. The only problem might be the
delay we observed on some windows machines but I think we should find a way to
reduce that delay instead of cheating with the start time.

[Benedikt Meurer, 2013-07-30 06:19:02]

LGTM.

[yurys, 2013-07-30 07:01:24]

Committed patchset #1 manually as r15944 (presubmit successful).