Hi Andy, What Erik said is absolutely correct. The profiler does 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. More solid approach is to profile a browser as a whole. Depending on an OS you're using, you may look at Intel VTune, OProfile, and Shark profilers. The problem with them, however, is that they're unaware of connection between compiled JS code and your JS sources, so you'll see anonymous code entries for JS code. To reveal interaction between JS and C++ (browser) code, you can build Chromium and use V8's internal profiler as described here: http://code.google.com/p/v8/wiki/ProfilingChromiumWithV8 OK, you may say, if showing JS and C++ interaction is possible, why Chrome's profiler doesn't do it? The answer is that to show C++ function entries, the profiler needs to access exported symbols of an executable, which isn't possible for a web application running in Chrome (and our profiler is really just a special web app.) In principle, it is possible to build a web app, which will be based on our profiler, and will allow to load C++ symbols and logs, and show them using the same UI. I even have such a prototype, but it's rather rough, so I'm not releasing it yet. On Sep 22, 9:58 am, Andy Chu <[email protected]> wrote: > On Mon, Sep 21, 2009 at 10:25 AM, Erik Kay <[email protected]> wrote: > > I'm not on the devtools team, but I'll take a swing at these. > > > On Sun, Sep 20, 2009 at 1:12 AM, Andy <[email protected]> wrote: > >> The profiling feature looks very cool. I'm profiling some expensive > >> JavaScript, but most of the profile is attributed to "(program)" -- > >> 80-90%. What does this mean? > > > I believe that means that it's something in the renderer process other > > than javascript code. So it could be layout, image decoding, DOM > > manipulation, etc. > > I see. But it would be a lot more useful to attribute those > activities to the function that is calling them, no? Or have a little > more breakdown other than the generic (program) category. It is not > just one page where I see this -- basically any page I do is showing > up ~90% (program), which leads me scratching my head at what code to > try to optimize. > > I think possibly theprofileris mostly useful for really CPU bound > code (like raytracing in JS or something). Most JS apps aren't like > that, so the output isn't so useful for all those cases. I see >95% > "(program)" and then 0.2% - 0.4% of 50 other things. If you look at > some random profiles of say Gmail you can see what I mean. > > > It's still a work in progress, so no docs yet. The quick answer on > > how it works is that it's a samplingprofiler. This means it doesn't > > account for 100% of code run (it may miss some very fast/short > > snippets of code), but that it's very lightweight, and does a pretty > > good job of identifying hotspots in your code. > > OK, that helps. But my problem is precisely to identify a general > hotspot, not do anything really detailed, and it isn't really useful. > It's great to have any JSprofilerat all though, so I look forward to > improvements. > > Andy --~--~---------~--~----~------------~-------~--~----~ Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss -~----------~----~----~----~------~----~------~--~---
