This should allow state to be more easily retained globally when switching views, and should make implementation of cross-view features like search easier too.
It also removes the need for `ReloadableComponent`
Fixes#78
Test Plan:
This changes a lot of how the app works, and a lot of stuff that isn't currently covered by tests, so here's a rough manual test plan:
1. Loaded up http://localhost:1234/, click to load the example profile
2. Switch between views, see that viewport & selection position is now retained when switching views
3. See that clicking on nodes selects them in Time Order & Left Heavy views
4. See that hitting Cmd+S saves a profile
5. See that dropping a profile in works
6. See that dropping a profile + a symbol map works
7. See that visiting localhost:1234/#profileURL=https://raw.githubusercontent.com/jlfwong/speedscope/master/sample/profiles/speedscope/0.1.2/simple-sampled.speedscope.json works
8. See that hitting "r" to toggle recursion flattening works
When importing files, there are two different paths we use for determining the file format.
The first is to pattern match on the filename.
If that fails, we fall back to examining the structure of the file, which can be slower and therefore wasteful.
Before this PR, we only tests that the filename pattern matching was correctly identifying the format. This PR ensures that our file structure matching is working correctly too.
This is an improvement to #76, which added support for asm.js symbol maps. This PR expands this to also work for emscripten's WebAssembly symbol maps too. This currently only works in Firefox. Chrome would need to fix https://crbug.com/863205 for this to be useful in Chrome.
This is being done in preparation for writing a format from rbspy to import into speedscope, whose internal file format is a list of stacks (111689fe13/src/storage/v1.rs (L13))
For now, speedscope will always export the evented format rather than the sampled format, but will accept either as input. I also added tests for existing versions of the file format to ensure I don't accidentally drop support for a past version of the file format.
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:
Fixes#15
