longtasks
longtasks copied to clipboard
w3c
Expose sampled call stacks
Can the api tell us a little more specific information about what snippet of code which is causing the long task ? May be the A call stack ?
Currently the containerSrc attribute is helpful if an iframe is causing the issue.(The culprit could be one of the many js files loaded to that iframe).
Yea, we know current attribution needs to be improved, although not sure when we'll get to work on this. How would the callstack to work when there are multiple top-level functions in a single longtask? Just provide one relevant callstack could work?
Maybe it should be an array of call stacks? But we definitely need something — at the moment I don't understand how to use it.
We're currently punting this, waiting to see if the Sampling Profiler API ships. If it does, we could benefit from it to expose some useful information about tasks that take long to execute. Hopefully soon :)
@npm1 what is Sampling Profiler API? I try to google it, but no luck, so any refs would be highly appreciated. Is it new awesome browser api?
It is a proposed API, although I'm not the one working on it: https://github.com/WICG/js-self-profiling
Hello there! Is this being reconsidered now with the work on the LoAF API?
I think this would be a great addition to have. It would provide a very simple and lightweight way to watch the JS Main Thread without having to make use of the Self Profiling API.
I am working on LoAF now, and trying to to find which function caused a long task.
With LoAF API, I can find sourceLocation in entry.srcipts[i], but it only give a character position of a file (even this position is not that precise).
How can I get call stack information like what is in the "Call Tree" tab under "Performance" in devtools?
^^ @noamr
How can I get call stack information like what is in the "Call Tree" tab under "Performance" in devtools?
I believe that would be too expensive to extract for an API that's on-by-default.
