This PR add a CLI speedscope which load file given as an argument in your default browser. Expected usage looks like:
```
speedscope /path/to/profile
```
Note that since we're using base64 encoded strings as a transport for this, this won't work with multi-file profiles, like the Instruments .trace files. This could be augmented to support that by archiving the contents, but that can be handled in a different PR.
This PR also set up a viable model for integrating speedscope into other projects. By replicating the contents of `cli.js` in other languages, integration should be possible in other languages with no dependency upon node in any way. Distribution should consist of just HTML, JS, and CSS assets to be loaded in browser.
Test Plan:
- Ran the following to simulate a publish & subsequent installation:
```
$ npm pack
$ mv speedscope-0.1.0.tgz /tmp/
$ cd /tmp
$ tar -xvvf speedscope-0.1.0.tgz
$ cd package
$ npm install --only=production
$ ./cli.js
Opening file:///private/tmp/package/dist/release/index.html in your default browser
$ ./cli.js ~/code/speedscope/sample/profiles/Chrome/65/timeline.json
Creating temp file /var/folders/l0/qtd9z14973s2tw81vmzwkyp00000gp/T/speedscope-1531023992823-3880.js
Creating temp file /var/folders/l0/qtd9z14973s2tw81vmzwkyp00000gp/T/speedscope-1531023992823-3880.html
Opening file:///var/folders/l0/qtd9z14973s2tw81vmzwkyp00000gp/T/speedscope-1531023992823-3880.html in your default browser
```
Fixes#24
This defines a JSON-based file format for speedscope.
The motivation for is primarily two things:
1. To enable others to write tools to output profiles which can be read by speedscope
2. To enable others to write tools to handle the output of speedscope, leveraging the variety of importers that speedscope supports
Fixes#65
This makes it easier to download speedscope to run totally offline, and makes embedding it into other applications easier since it no longer depends on specific URL paths.
I'm not sure why this happens, but I have multiple profiles coming from Chrome that have negative values in the exported `timeDelta` objects.
This PR also cleans up some of the error reporting logic to hopefully stop logging `undefined` to the console on import failure.
Fixes#70
At some point in the past, the code splitting of demangle-cpp got broken. This fixes that and also code splits out all fo the different profile importers into their own module since they aren't needed for initial render of the page.
This imports symbol maps generated by emscripten using the `--emit-symbol-map` flag. It allows you to visualize a profile captured in a release build as long as you also have the associated symbol map. To do this, first drop the profile into speedscope and then drop the symbol map. After the second drop, the symbols will be remapped to their original names.
This is a fixed up version of #75
This cleans up imported Chrome profiles in 2 ways:
1. It places `(program)` frames on top of the previous call stack, just like we already did for `(garbage collector)`
2. It completely removes `(root)` and `(idle)` frames, since they aren't semantically useful in the profiles
CC @evanw
I knew early on that `integeruniquer.index` could be used to index into `integeruniquer.data`, but I initially thought it was an optimization rather than a necessity. It seems like if there's data past the 1MB threshold in `integeruniquer.data`, then `integeruniquer.index` is actually quite useful.
The file seems to contain `[byte offset, MB offset]` pairs encoded as two 32 bit unsigned little endian integers. Using that to decode the integer arrays encoded in `integeruniquer.data` allows the file in #63 to load.
Fixes#63
* Split profile building APIs into dedicated classes
* Split value formatters into their own file
* Add tests for formatters
* Add test for StackListProfileBuilder
* Add test for CallTreeProfileBuilder
* Tests for clamp, Vec2
* Switch to using jsverify for testing math functions
* Add tests for AffineTransform
* Add tests for Rect
* Add tests for rect transformations
This switches all text to be Source Code Pro instead of Courier for sharper rendering at size 10.
This also changes outline widths to be consistent visual widths on retina and non-retina screens.
This contains 2 fixes for the details view
The first is that the padding in the scrolling view was causing the last frame to be clipped
The second is that we were uselessly displaying "(speedscope root)" in the stack trace view.
This also removes some sketch specific stuff from the keyed archive expanding code
Fixes#32
#33 added support for importing from instruments indirectly via opening instruments and using the deep copy command. This PR adds support for importing `.trace` files directly, though only for time profiles specifically, and only for the highest sample count thread in the profile.
This PR adds `.trace` files from Instruments 9, and adds support for importing from either Instruments 8 and 9. The only major difference in the file format seems to be that Instruments 9 applies raw `zlib` compression generously throughout the file.
This PR also adds example `.trace` files for memory allocations, which are not supported for direct import. They use a totally different storage format for recording memory allocations, and I haven't yet figured out how that list of allocations references their corresponding callstack.
Lastly, this PR also adds examples from Instruments 7 since I happen to have a machine with an old version of Instruments. Import from Instruments 7 probably wouldn't be hard to add, but I haven't done that in this PR.
This currently only works in Chrome, and only via drag-and-drop of the files.
To test, drag the decompressed `simple-time-profile.trace` from 6016d970b9/sample/profiles/Instruments/9.3.1/simple-time-profile.trace.zip onto speedscope.
The result should be this:
![image](https://user-images.githubusercontent.com/150329/40162338-8fa13502-5968-11e8-8fb3-40626e41884a.png)
Fixes#15
This should help keep things organized as speedscope supports more languages & more formats
Test Plan: Try importing from every single file type, see that the link to load the example profile still works
![image](https://user-images.githubusercontent.com/150329/38852391-9706fb4e-41ce-11e8-8296-a236928820c6.png)
This introduces a view for showing detailed information about a selected frame in the flamegraph. This provides information about self time & aggregate times across all instances of the function, regardless of where it is in the flamegraph.
This also shows a full stack with file & line information.
Fixes#20
On init, we check the hash fragment for these parameters and load the URL. We
always show a loading state in that case rather than the landing screen.
When determining the title, an explicitly-specified title takes precedence,
otherwise we use the filename.
I also added an error state, currently only used for my new code, but possibly
there could be a more robust or widespread error handling approach in the
future.