Re: Long Tasks Notifications API

On Mon, Aug 8, 2016 at 3:56 PM, Shubhie Panicker <panicker@google.com>
wrote:

> Looking into this some more on Google sites (G+, Photos) that I am able to
> deobfuscate -- that's right: in cases of V8.callFunction the top level
> function is often a generic framework function.
>
> This sure indicates that we should implicate function calls lower in the
> stack where "self time" exceeds a threshold, although including "time
> in children" would be more relevant in many cases where there isn't one
> clear culprit and instead the sum of the things is resulting is blowing the
> threshold.
> There isn't an easy answer here obviously, and we'll definitely need to
> experiment and come up with some heuristics to attribute blame without
> needing to return detailed callstacks through this API.
> Would love to involve you and discuss further when we start focusing on
> this part of the API (in V2, not V1)
> You've made a great point and it is well taken :)
>
> BTW In the case of V8.compile and V8.run -- there is a script URL
> available, which seems a bit more useful. OTOH V8.callFunction is quite
> common after page load - especially for sites like Facebook, G+ etc
>

Totally understand this may be deferred to V2. One thing I'd point out is
that on a site like FB script URL is often not really all that helpful
(even if you skip the framework file). Often a site bundles lots of stuff
together in a single package. At FB we automatically choose our packaging
based on historical usage patterns. So JS for newsfeed and chat might get
packaged together if they are used on the same set of pages. If we provide
line/column info that might be more useful (since that can unambiguously
identify a function and a developer can use source maps to figure out
exactly what the function was).

One option -- what about returning the Function object that was called, if
that function was in the same document. That way an interested site can
attach metadata to the function object (for example, if the function is a
wrapper a pointer to the real function). At least at FB we already do this
so it would fit in pretty well with our existing frameworks.

IMHO if we wanted to get any more complex than this it might make sense to
try to provide a sampling profiler in JS. But that sounds like v3 :-)



> I see. With your current implementation how would time spent in extensions
>> show up?
>>
> Whoops, this will be the document the extension is running in, so it could
> be one of the the top level pages / tabs.
>

Is there any chance you guys could say "this is a content script" but not
tell us anything about which extension it is. Being able to identify that
time is being spent in an extension would be a great way to get web
developers to put pressure on browser vendors to reign in the perf impact
of extensions (assuming that there is a perf issue). Even if the developer
can't identify which extension is causing hte problem presumably the
browser could start collecting more general stats on the perf impact of
each extension.