jlfwong / speedscope Goto Github PK

There is Google protobuf-based file format used for profilers in Google tooling, and is more specifically used by go tool pprof.

https://github.com/google/pprof/tree/master/proto
https://blog.golang.org/profiling-go-programs

What's the license for this repository? I don't see it in the README or in the repo.

It'd be great to add a LICENSE file to the repository to make this clear.

This project looks really nice!

It would be nice if you could run speedscope /path/to/profile.json and have it either automatically open in your browser of choice or boot up speedscope in an electron shell. This would make integration with other tools potentially much easier.

This will be helpful for supporting both multiprocess/multithread Instruments import (#63) and general trace import (#77)

This is required for #31.

Here's a rough toolbar mockup showing navigation controls between the profiles from different threads/processes.

For some reason, the example profile is running really slowly, but only in Chrome. It seems like most of the time is going into compositing layers

It seems to run just fine in Firefox

It would be really nice to be able to quickly locate functions within a profile by highlighting them via search.

Here are some mockups of what that might look like:

The following profile:

a;b 1
a 3
a;b 5

Should contain 3 CallTreeNode objects. But it currently contains 2: one for a with self-weight 3, and one for b with self-weight 6.

Chrome has a simplified trace format which is a json list of trace dictionaries. This is the main format we generate internally at our company, so it would be nice if speedscope could render them.

This test trace file loads in chrome://tracing while it gives an error in speedscope.

test.json.zip

Ideally I'd be able to zoom out using the browser's zoom to be able to compress deeper traces. Right now the UI gets really messed up if you do that. It looks like there are two separate layers that are both the wrong scale in different ways?

It looks like Chrome's latest release changed the format again. Traces captured in Chrome Canary cannot be loaded.

In the DevTools (and about:tracing) we allow panning Y axis with A/D and zooming Y axis with W/S. I've come to heavily rely on that, so I'd lurve if it was supported here, too.

Greattt work on this app. So nice.

Mockup:

Export can lock up speescope for a while. It should be easy enough to pop up a progress bar.

If you do multiple runs of a trace, it seems like speed scope only renders the last run? Or kind of merges them together? It's kind of hard to tell.

Here is an example trace on safari.

Maybe a run selector needs to be added?

2-run-safari-instruments-v9.trace.zip

https://kcachegrind.github.io/html/CallgrindFormat.html

This is also a common format output by some other profiles, like XDebug for PHP (https://xdebug.org/docs/profiler)

When trying to open an instruments time tracing trace, speedscope fails to load it with an error. Pasting in a deep copy of the same trace works. The error that shows up in the JS console is just 'undefined'

Here is an example trace that fails. I created it by tracing xcode 9.4 for a few seconds.
xcode.trace.zip

Repro: zoom in really far. Sometimes the loop in this picture hangs because the loop offset plus the loop increment ends up being rounded down to the loop offset (i.e. the increment has no effect). A check for that condition such as if (t + n === t) break would fix this here.

The viewport & selection should be maintained for the flamegraphs, and the sort order, scroll offset, and selection should be maintained for the sandwich view

This should be helpful in cases where an expensive function shows up in many different stacks (e.g. if you had an expensive function used at various recursive depths in a compiler).

Inspired by the tree view in KCacheGrind: https://kcachegrind.github.io/html/Shot3.html

https://github.com/rbspy/rbspy

For a complex, heavily multi-threaded app, the logic that assumes that the thread with the most samples is the main thread can be mislead.

Sadly, I don't have a concrete suggestion for something better. I notice that main appears to usually be thread id '4', but there has to be something less hacky.

Just wanted to open this issues to start a discussion about this.

Not sure how this is happening

In time ordered view, it would be useful to be able to crop along the time axis to the current viewport. This would allow for more meaningful statistics around where the time is going within some specific time span (e.g. a single request or a single frame).

Maintaining the viewport between the two views isn't helpful, and sometimes results in buggy behavior when the bounds of the two views are different because e.g. the left heavy view drops idle time from the profile

First, it would really help if we could simplify how time > 1 minute is shown. It's hard to parse 1.20min as 1:12 (have to constantly multiply the fraction by 60 to understand seconds).

Second, only 2 decimals are shown, once you pass 1 minute, instead of 10ms as the finest grain now you only see 0.01 minutes (600ms) as the finest grain. To improve this it would be best if we could get a mm:ss.iii format (minutes:seconds.millisconds) instead. You can look at the timeline in Instruments to see a demo of what this would look like.

Thanks!

This should be doable via a service worker (https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API)

Since this app can read many trace formats, it would be pretty cool if we could have an export function into some sort of common JSON format. That way we can use it to convert things like proprietary instruments traces into open chrome traces so we can use it with other tools.

It looks like someone else has already done the hard work of figuring out the file format! https://rhye.org/post/android-profiling-flamegraphs/

I bought speedscope.app, might as well use it!

There are no unit tests for this repository yet!

Some of the areas that should be pretty easy to write tests for:

• importFromChromeTimeline
• importFromChromeCPUProfile
• importFromStackprof
• importFromBGFlameGraph
• The methods of the Profile class
• The methods of the Flamechart class
• The LRUCache class
• The Vec2 class
• The AffineTransform class
• The Rect class

Trickier tests that would require some form of visual diffing + a GPU (or CPU implementation of gl like headless-gl, but are otherwise pretty stable with well defined interfaces

• ViewportRectangleRenderer
• TextureRenderer
• RectangleBatchRenderer
• FlamechartRenderer

And then there's the matter of tests for the UI itself

A dotted blue line should suffice

#61 was caused by me zooming in really far at the end of the run to try to measure the overall time since that's not displayed in the UI anywhere. Displaying that in the UI somewhere would mean I wouldn't have hit this bug in the first place :)

I'm making a chrome devtools extension to surface the results of server-side profiling, and I tried hacking speedscope in as a React component, but I ran into some issues. From my perspective, it would be great if I could install speedscope as a library and render it as a React component with the full text of the profile as a prop.

Here's a partial list of issues that would need to be addressed for this to happen:

• You need to actually build it as a library and publish it on npm. 😄My hacky approach was to just npm link the TypeScript into my node_modules and compile it with webpack, but that ran into various issues. If you want to avoid the React dependency (or peer dependency), you could ship a @speedscope/core and separate @speedscope/react package, or something like that.
• Speedscope uses Preact, which isn't drop-in compatible with React. Probably the best way to ship a React-friendly speedscope component is to just write a React wrapper that mounts a Preact render tree inside, rather than trying to make the whole thing a React render tree.
• I ran into CSP issues since regl uses eval. I was able to enable eval for my extension to work around it, but I'd prefer not to. This seems like it might be unreasonable to work around, but it would be a good thing to mention in docs.
• Formatting looked wrong because speedscope includes reset.css, which it turns out is necessary. The aphrodite styles just worked, though, which was nice.
• The profile rendered correctly and various interactions worked, but hover and pinch zoom didn't do anything, and drag-to-pan caused the main flamechart view to just disappear. This might just be due to React/Preact differences, not sure.

So at least for now, it looks like an iframe (or external window) is the nicest way to use speedscope, and from what I can see that works fine. But it would be cool if it could be more integrated into a larger tool.

The developer tools in Chrome's latest release are super buggy, so I'd like to use Firefox for profiling instead. I can't find any documentation about the format unfortunately. It looks like it's JSON-based.

It would be awesome to get data from Instruments.app into speedscope to get nice visualizations out of XCode

Padding should be tweaked (at least) for non-retina screens to prevent outlines from obscuring the actual text

https://github.com/mapbox/flamebearer should be a helpful reference

It seems like subpixel text anti-aliasing is disabled for non-opaque canvases: https://stackoverflow.com/questions/4550926/subpixel-anti-aliased-text-on-html5s-canvas-element

If all rendering was switched to WebGL rather than a combination of WebGL + Canvas, this could be solved by creating a text atlas with glyphs that are already subpixel AA'd