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 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
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
* Install prettier, set up the config file, and run it on all ts and tsx files.
* Install eslint and configure it with just eslint-plugin-prettier to check to
make sure that prettier has been run.
* Add a basic .travis.yml that runs eslint.
There are other style things that might be nice to enforce with ESLint/TSLint,
like using const, import order, etc, but this commit just focuses on prettier,
which gets most of the way there.
One annoying issue for now is that typescript-eslint-parser gives a big warning
message since they haven't updated to officially support TypeScript 2.8 yet. We
aren't even using any ESLint rules that need the parser, but if we don't include
it, ESLint will crash. TS2.8 support is hopefully coming really soon, though:
https://github.com/eslint/typescript-eslint-parser/pull/454
As for the prettier config specifically, see https://prettier.io/docs/en/options.html
for the available options.
Config settings that seem non-controversial:
Semicolons: You don't use semicolons. (I prefer semicolons, but either way is fine.)
Quote style: Looks like you consistently use single quotes outside JSX and double
quotes in JSX, which is the `singleQuote: true` option.
Config settings worth discussion:
Line width: You don't have a specific max. I put 100 since I think it's a good number
for people (like both of us, probably) who find 80 a bit cramped. (At Benchling we use
110.) Prettier has a big red warning box recommending 80, but I still prefer 100ish.
Bracket spacing: This is `{foo}` vs `{ foo }` for imports, exports, object literals,
and destructuring. Looks like you're inconsistent but lean toward spaces. I personally
really dislike bracket spacing (it feels inconsistent with arrays and function calls),
but I'm certainly fine with it and Prettier has it enabled by default, so I kept it
enabled.
Trailing comma style: Options are "no trailing commas", "trailing commas for
everything exception function calls and parameter lists", and "trailing commas
everywhere". TypeScript can handle trailing commas everywhere, so there isn't a
concern with tooling. You're inconsistent, and it looks like you tend to not have
trailing commas, but I think it's probably best to just have them everywhere, so I
enabled them.
JSX Brackets: You're inconsistent about this, I think. I'd prefer to just keep the
default and wrap the `>` to the next line.
Arrow function parens: I only found two cases of arrow functions with one param
(both `c => c.frame === frame`), and both omitted the parens, so I kept the
default of omitting parens. This makes it mildly more annoying to add a typescript
type or additional param, which is a possible reason for always requiring parens.
Everything else is non-configurable, although it's possible some places would be
better with a `// prettier-ignore` comment (but I usually try to avoid those).
