On Thu, Nov 8, 2012 at 7:03 PM, <bsr...@gmail.com> wrote:
> Hope this is the official group for Developer Tool.
It is!
> In Safari, I can see Average and #calls, but there I can't see any %ge ,
> actual time settings. So, I don't have an idea of actual time.
> Chrome dev tools has everything I need, except the #calls to a function.
> Please help me to enable it.
Safari and Chrome use different JavaScript engines (JSC in Safari and v8 in
chrome) and the profilers are different. JSC has an instrumenting profiler,
meaning it records every call to the function, and v8's profiler is a
statistical one, meaning it pokes into the stack of the running code
periodically (typically once in 1ms now) and accounts time to various
functions depending on how often they appear on the stack. As a result, the
numbers are somewhat approximate and we can't get the exact invocation
counts for each function.
In safari and Firefox, I saw recursive calls to create svg elements (about 10k times). The attached image, as well as the one in SO shows the profile of just the draw function (which in turn recursively create nodes). It shows a total time of 20sec, but I can't see what causes it. Can you please advise how I can narrow down to the bottleneck.
On Thursday, November 8, 2012 10:14:11 AM UTC-5, Andrey Kosyakov wrote:
> Hi,
> On Thu, Nov 8, 2012 at 7:03 PM, <bsr...@gmail.com <javascript:>> wrote:
>> Hope this is the official group for Developer Tool.
> It is!
>> In Safari, I can see Average and #calls, but there I can't see any %ge , >> actual time settings. So, I don't have an idea of actual time.
>> Chrome dev tools has everything I need, except the #calls to a function. >> Please help me to enable it.
> Safari and Chrome use different JavaScript engines (JSC in Safari and v8 > in chrome) and the profilers are different. JSC has an instrumenting > profiler, meaning it records every call to the function, and v8's profiler > is a statistical one, meaning it pokes into the stack of the running code > periodically (typically once in 1ms now) and accounts time to various > functions depending on how often they appear on the stack. As a result, the > numbers are somewhat approximate and we can't get the exact invocation > counts for each function.
We account to (program) samples that did not have any JavaScript stack --
so those 20s you have shown as (program) is not JavaScript or anything
invoked from JavaScript. This leaves to major cases that
you unfortunately can't distinguish with the profiler so far: idle time or
some native code not invoked from JS (this often happens to be layout &
painting stuff that happens asynchronously). A good way to identify whether
this is idle time or something else would be to use Timeline panel. You may
also find an option "Show CPU activity on the ruler" useful (we added it
recently, so it's only available in canary builds so far).
On Thu, Nov 8, 2012 at 8:53 PM, <bsr...@gmail.com> wrote:
> Thanks Andrey,
> In safari and Firefox, I saw recursive calls to create svg elements (about
> 10k times). The attached image, as well as the one in SO shows the profile
> of just the draw function (which in turn recursively create nodes). It
> shows a total time of 20sec, but I can't see what causes it. Can you please
> advise how I can narrow down to the bottleneck.
> On Thursday, November 8, 2012 10:14:11 AM UTC-5, Andrey Kosyakov wrote:
>> Hi,
>> On Thu, Nov 8, 2012 at 7:03 PM, <bsr...@gmail.com> wrote:
>>> Hope this is the official group for Developer Tool.
>> It is!
>>> In Safari, I can see Average and #calls, but there I can't see any %ge ,
>>> actual time settings. So, I don't have an idea of actual time.
>>> Chrome dev tools has everything I need, except the #calls to a function.
>>> Please help me to enable it.
>> Safari and Chrome use different JavaScript engines (JSC in Safari and v8
>> in chrome) and the profilers are different. JSC has an instrumenting
>> profiler, meaning it records every call to the function, and v8's profiler
>> is a statistical one, meaning it pokes into the stack of the running code
>> periodically (typically once in 1ms now) and accounts time to various
>> functions depending on how often they appear on the stack. As a result, the
>> numbers are somewhat approximate and we can't get the exact invocation
>> counts for each function.
