Join GitHub today
Replace the custom flamegraph viewer with speedscope #100
This PR replaces the custom flamegraph viewer introduced by @aroben in #74 (which sounds like it was a huge improvement over the existing SVG viewer!) with an integration of a high performance, WebGL-based, language agnostic profile viewer that I've been working on called speedscope: https://github.com/jlfwong/speedscope.
If you don't think this is a good fit for this repository, no worries! I'm happy to either just close this PR, or to change it to be a dramatically reduced version which just makes it easier to output a format that speedscope can consume (basically just the
A script is included (
It should be able to easily handle profiles at least as large as the existing viewer, and zooming & panning should remain 60fps within those very large profiles through efficient use of the GPU for rendering.
I also preserved the original workflow of doing a separate compilation & opening step:
This should open the profile in-browser in both Linux and OS X using whatever your default configured browser is. I've only tested on OS X to date on Firefox & Chrome, but it shouldn't be OS dependent.
So I think I might have more to say, but since I don't even have merge rights and have just been "nerd sniped" into reviewing because I use this repo myself regularly, I gave some comments.
Mostly personal opinion here, so feel free to take it or leave it.
Seems cool regardless!
I have not, but have this integrated into https://github.com/jlfwong/rack-mini-profiler, which we use to profile a sinatra app regularly at Figma.
We also use speedscope at Figma to open 100MB+ profiles generated by Chrome, which it handles relatively gracefully.
We need to make sure the viewer and JSON are separate (it looks like this PR will do that), but also ensure we can print the flamegraph JSON data to an IO of our choosing. I think this PR removes the that ability (though I could be wrong because the diff is pretty large
As long as we have an API that can ensure those things, then I'm happy.
Hmm. It's going to be a bit tricky, but it's doable. The reason it downloads other things is to speed up loading so that it can present a UI and allow users to browse for a file without needing to wait for all the code that does the actual importing.
If I'm going down that path anyway, would you prefer that everything is inlined into the
I'll look into it when I change the codepaths to split
referenced this pull request
Aug 1, 2018
@tenderlove To be clear, are you talking about
I'm curious how you have this set up with the current flamechart viewer, given that I thought it loads scripts dynamically too?
@tenderlove My working assumption is that you have a
Okay, @tenderlove I updated the PR using a build which shouldn't do any dynamic script loading. The work is based on an open PR on speedscope, so I pulled in the tarball for it manually rather than using
Here's the relevant PR on speedscope if you're curious: jlfwong/speedscope#113
@jlfwong hey, sorry it took so long to get back to you. Yes, our CSP won't allow
My goal is that folks at work can just click a link and see flame graphs of the page.
I really want this in stackprof because it's hands down better than the existing one. Maybe we could keep an API that outputs data that will work with the old viewer?
@tenderlove Got it. Yeah, that makes sense!
Definitely a noble goal :)
A couple of alternative options to potentially consider. You've probably thought of these already, but just to make sure that these are all show-stoppers:
If those are both no-gos, then I'll look into either preserving the existing flamechart viewer or into switching the WebGL abstraction I'm using to one which doesn't use
referenced this pull request
Aug 19, 2018
@tenderlove Okay, I've updated the PR to use a version which does not use eval.
To validate that it was working, I opened it via a local server and specified the following header:
I was able to validate that the version before the removal of
Can you see if this now works for GitHub's content security policy?
If it turns out that I'm wrong and that both the eval calls and the dynamic file loading were causing issues, I can easily switch this to a build that has both removed.