gregtatum
commented
6 years ago On the JS side of things, the Gecko profiler provides us with only the line information for the function itself, not for where we were in the function.
For instance with this html file:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Slow single function</title>
</head>
<body>
This file demonstrates a slow function that is slow on different lines.
<script>
function doWork () {
let i = 0
const step = 50000;
console.time('doWork')
for (; i < 1 * step; i += Math.random()) {}
for (; i < 2 * step; i += Math.random()) {}
for (; i < 3 * step; i += Math.random()) {}
for (; i < 4 * step; i += Math.random()) {}
console.timeEnd('doWork')
console.log('Done doing work', i)
}
doWork();
</script>
</body>
</html>For each frame entry in the thread, the Gecko profiler has a string location field. This location points to the following string: "doWork (file:///Users/gregorytatum/Desktop/html/slow-single-function.html:11)"
The :11 is the line function doWork () { in the above example. In an ideal world we could have the line and column information, especially as sources are often minified.
From there if we could fetch the sources, then we could potentially then place blame on where exactly time was spent within a JS function. This information could then be surfaced in a sidebar panel, OR a sources view.
mstange
Here is an example perf problem that involves a single hot function. I had to fix it by instrument the function itself with timing information.
This is a JS only example, it would be nice to have a C++ example.
From PR #695 Before: https://perfht.ml/2qs05TQ After: https://perfht.ml/2qrczLn
┆Issue is synchronized with this Jira Task