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.
>
>
> On Fri, Aug 5, 2016 at 4:04 PM, Ben Maurer <ben.maurer@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 5, 2016 at 3:22 PM, Shubhie Panicker <panicker@google.com>
>> wrote:
>>
>>> - Re: callback wrappers
>>> As seen in the common script execution patterns
>>> <https://docs.google.com/document/d/1UCJHjDB5ttYdDH3B9xggev10euRV3wsRR3jCoQi9AwM/edit>
>>> - there’s a couple different frequent patterns.
>>> For v8.run the URL is available; for direct entry into callFunction we
>>> have the obfuscated / minified function name string -- this is similar to
>>> what you’d see in Devtools timeline with JS Profile. (You’d deobfuscate
>>> using your own pipeline)
>>> From a quick look at Devtools Js Profile on facebook -- I do see a
>>> frequently occurring entry point for scripts - this is probably your
>>> wrapper.
>>> We should probably discuss your specific wrapper situation offline, as I
>>> don't see this as a very common pattern on other top sites.
>>>
>>
>> Yeah, that's very likely our wrapper. Happy to discuss potential
>> solutions offline. A bit surprised this pattern hasn't shown up in other
>> sites.
>>
>
>
>
>
>>
>>
>>> - Re: extensions
>>> We *may* be able to indicate something generic here. Prior investigation
>>> <https://codereview.chromium.org/1615523002/> indicates that it's very
>>> difficult to properly account for scripts spawned by extensions.
>>>
>>
>> I see. With your current implementation how would time spent in
>> extensions show up?
>>
> I'm pretty sure this will not get attributed to the "frame context" for
> any of the toplevel pages / tabs. Will do a test to see exact context URL.
>
Whoops, this will be the document the extension is running in, so it could
be one of the the top level pages / tabs.


>
>> -b
>>
>>
>