While it was kind of nice having everything at the top level, the number of files is now getting a bit unwieldy and hard to understand, so I took a stab at organizing the directories without introducing too much nesting.
Test Plan:
- Ran `npm run serve` to ensure that local builds still work
- Ran `npm run prepack` then `open dist/release/index.html` to ensure that release builds still work
- Ran `scripts/deploy.sh` to ensure that the deployed version of the site will still work when I eventually redeploy
- Ran `npm run jest` to ensure that tests still work correctly
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
