> OK, I see. But then I have to ask why it has to be a sampling
> profiler. An instrumented profiler will reveal the time spent outside
> of JS code (but still called from JS code).
>
You're a bit misguided. Sampling vs. instrumenting is orthogonal to
this issue. Instrumenting JS profilers (the ones you can find in IE8,
FireBug for FireFox, and Safari) can show you the exact number of
calls made, but they are still limited to showing you JS code only.
> As a more concrete example, if some JS code is making 100,000 calls to
> some expensive function, say document.getElementById('foo'), then the
> profiler should show me this block under the function that called it,
> rather than lumping it in with the rest of the time spend rendering
> images, etc. Maybe I will cook up a test of this to show the problem.
>
That's a good idea. I will try to implement this.
On Thu, Sep 24, 2009 at 06:11, Andy <[email protected]> wrote:
>
>
> On Sep 22, 11:51 am, Mikhail Naganov <[email protected]> wrote:
>> Hi Andy,
>>
>> What Erik said is absolutely correct. Theprofilerdoes sampling, and
>> if it sees samples that can't be attributed to JS code (that is,
>> rendering, DOM, etc.), it accounts them to '(program)' entry.
>>
>> If your web app's most weight is in '(program)' entry, this means that
>> your JS code just isn't heavy enough, in other words, your hot spot
>> isn't on JS side. What to do in this case? You can try to use another
>> tool, like "Page speed" (http://googlecode.blogspot.com/2009/06/
>> introducing-page-speed.html) to get some insights.
>
> OK, I see. But then I have to ask why it has to be a sampling
> profiler. An instrumented profiler will reveal the time spent outside
> of JS code (but still called from JS code).
>
> The reason is that if I my bottleneck is DOM manipulation, then to fix
> it, I need it to be attributed to some JS code! After all, the only
> thing I can change is JS code. I can't speed up Chrome as an
> application writer, and that is besides the point because we're
> writing cross-browser JS code. Often I have a bunch of third party
> code, and I don't even know what kind of DOM manipulation it's doing.
>
> I think this is a rather severe problem. Have you seen lots of real
> JS apps that spend most of their time strictly in the JS interpreter?
> I used it on Gmail, and although I'm not a Gmail developer, it doesn't
> seem very useful (aside from the obfuscated function names), as 90% of
> the time is an opaque block.
>
> As a more concrete example, if some JS code is making 100,000 calls to
> some expensive function, say document.getElementById('foo'), then the
> profiler should show me this block under the function that called it,
> rather than lumping it in with the rest of the time spend rendering
> images, etc. Maybe I will cook up a test of this to show the problem.
>
> Andy
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Discussion mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-discuss
-~----------~----~----~----~------~----~------~--~---
