-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support importing profiles whose contents exceed V8s maximum string size #385
Conversation
package.json
Outdated
@@ -53,6 +53,7 @@ | |||
"ts-jest": "24.3.0", | |||
"typescript": "4.2.3", | |||
"typescript-json-schema": "0.42.0", | |||
"uint8array-json-parser": "^0.0.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would adding a single dependency add 15000 lines to the package-lock.json file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh. It's a good question.
My guess is something to do with the lockfileVersion
change: https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json#lockfileversion
Before this change, the package-lock.json
was lockfileVersion: 1
, and after the chang eit was lockfileVersion: 2
. This has nothing to do with this change, it just so happens this is the first time I've installed something since the npm version change.
…#408) In #385, I introduced a dependency on the `uint8array-json-parser` npm package, but used a fork because of a typescript error. This was resolved in evanw/uint8array-json-parser#1 and published as part of `uint8array-json-parser@0.0.2`. Let's use the upstream. This also conveniently fixes a new typechecking error that was preventing deployment. The error looked like this: ``` src/import/utils.ts(2,26): error TS2306: File '\''/Users/jlfwong/code/speedscope/node_modules/uint8array-json-parser/uint8array-json-parser.ts'\'' is not a module.' ``` After updating to the upstream, the problem is fixed.
Currently, importing files generated by linux perf tool whose some blocks exceed V8 strings limit can crash the application. This issue is similar to the one in jlfwong#385. This PR fixes it by changing parseEvents to work directly with lines instead of chunking lines into blocks first. Fixes jlfwong#433
Currently, importing files generated by linux perf tool whose some blocks exceed V8 strings limit can crash the application. This issue is similar to the one in jlfwong#385. This PR fixes it by changing parseEvents to work directly with lines instead of chunking lines into blocks first. Fixes jlfwong#433
Currently, importing files generated by linux perf tool whose some blocks exceed V8 strings limit can crash the application. This issue is similar to the one in jlfwong#385. This PR fixes it by changing parseEvents to work directly with lines instead of chunking lines into blocks first. Fixes jlfwong#433
…ize (jlfwong#385) Browsers have a limit on how big you can make strings. In Chrome on a 64 bit machine, this is around 512MB, which explains why in jlfwong#340, a 600MB file fails to load. To work around this issue, we avoid making strings this large. To do so, we need two core changes: 1. Instead of sending large strings as the import mechanism to different file format importers, we introduce a new `TextFileContent` interface which exposes methods to get the lines in the file or the JSON representation. In the case of line splitting, we assume that no single line exceeds the 512MB limit. 2. We introduce a dependency on https://github.com/evanw/uint8array-json-parser to allow us to parse JSON files contained in `Uint8Array` objects To ensure that this code doesn't code rot without introducing 600MB test files or test file generation into the repository, we also re-run a small set of tests with a mocked maximum string size of 100 bytes. You can see that the chunked string representation code is getting executed via test coverage. Fixes jlfwong#340
…jlfwong#408) In jlfwong#385, I introduced a dependency on the `uint8array-json-parser` npm package, but used a fork because of a typescript error. This was resolved in evanw/uint8array-json-parser#1 and published as part of `uint8array-json-parser@0.0.2`. Let's use the upstream. This also conveniently fixes a new typechecking error that was preventing deployment. The error looked like this: ``` src/import/utils.ts(2,26): error TS2306: File '\''/Users/jlfwong/code/speedscope/node_modules/uint8array-json-parser/uint8array-json-parser.ts'\'' is not a module.' ``` After updating to the upstream, the problem is fixed.
Currently, importing files generated by linux perf tool whose some blocks exceed V8 strings limit can crash the application. This issue is similar to the one in jlfwong#385. This PR fixes it by changing parseEvents to work directly with lines instead of chunking lines into blocks first. Fixes jlfwong#433
Browsers have a limit on how big you can make strings. In Chrome on a 64 bit machine, this is around 512MB, which explains why in #340, a 600MB file fails to load.
To work around this issue, we avoid making strings this large.
To do so, we need two core changes:
TextFileContent
interface which exposes methods to get the lines in the file or the JSON representation. In the case of line splitting, we assume that no single line exceeds the 512MB limit.Uint8Array
objectsTo ensure that this code doesn't code rot without introducing 600MB test files or test file generation into the repository, we also re-run a small set of tests with a mocked maximum string size of 100 bytes. You can see that the chunked string representation code is getting executed via test coverage.
Fixes #340