2021-01-25 17:41:20 +03:00
|
|
|
# This file is automatically @generated by Cargo.
|
|
|
|
# It is not intended for manual editing.
|
2021-10-30 16:04:07 +03:00
|
|
|
version = 3
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "Inflector"
|
|
|
|
version = "0.11.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fe438c63458706e03479442743baae6c88256498e6431708f6dfc520a26515d3"
|
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"regex",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "addr2line"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.17.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "b9ecd88a8c8378ca913a680cd98f0f13ac67383d35993f86c90a70e3f137816b"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"gimli",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "adler"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "1.0.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "f26201604c87b1e01bd3d98f8d5d9a8fcbb815e8cedb41ffccbeb4bf593a35fe"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "aes"
|
|
|
|
version = "0.7.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9e8b47f52ea9bae42228d07ec09eb676433d7c4ed1ebdf0f1d1c29ed446f1ab8"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"cipher",
|
|
|
|
"cpufeatures",
|
|
|
|
"opaque-debug 0.3.0",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "aho-corasick"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.7.18"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "1e37cfd5e7657ada45f742d6e99ca5788580b5c529dc78faf11ece6dc702656f"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "aliasable"
|
|
|
|
version = "0.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "250f629c0161ad8107cf89319e990051fae62832fd343083bea452d93e2205fd"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "analytics"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2022-05-17 06:13:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ansi_term"
|
|
|
|
version = "0.12.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d52a9bb7ec0cf484c551830a7ce27bd20d67eac647e1befb56b0be4ee39a55d2"
|
|
|
|
dependencies = [
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "anyhow"
|
2022-05-03 20:54:48 +03:00
|
|
|
version = "1.0.57"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-03 20:54:48 +03:00
|
|
|
checksum = "08f9b8508dccb7687a1d6c4ce66b2b0ecef467c94667de27d8d7fe1f8d2a9cdc"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "approx"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f0e60b75072ecd4168020818c0107f2857bb6c4e64252d8d3983f6263b40a5c3"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
|
|
|
name = "approx"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3f2a05fd1bd10b2527e20a2cd32d8873d115b8b39fe219ee25f42a8aca6ba278"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
2022-02-22 19:43:37 +03:00
|
|
|
[[package]]
|
|
|
|
name = "approx"
|
|
|
|
version = "0.5.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cab112f0a86d568ea0e627cc1d6be74a1e9cd55214684db5561995f6dad897c6"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "arc-swap"
|
|
|
|
version = "1.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c5d78ce20460b82d3fa150275ed9d55e21064fc7951177baacf86a145c4a4b1f"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ascii"
|
|
|
|
version = "0.9.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "eab1c04a571841102f5345a8fc0f6bb3d31c315dec879b5c6e42e40ce7ffa34e"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "assert-json-diff"
|
|
|
|
version = "2.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "50f1c3703dd33532d7f0ca049168930e9099ecac238e23cf932f3a69c42f06da"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "assert_approx_eq"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3c07dab4369547dbe5114677b33fbbf724971019f3818172d59a97a61c774ffd"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ast"
|
|
|
|
version = "0.1.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"ast-macros",
|
|
|
|
"derive_more",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-prelude",
|
2022-05-16 15:28:50 +03:00
|
|
|
"enso-profiler",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-shapely",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-10 16:36:08 +03:00
|
|
|
"failure",
|
|
|
|
"lazy_static",
|
|
|
|
"regex",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"shrinkwraprs 0.2.3",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ast-macros"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
|
|
|
"enso-macro-utils",
|
|
|
|
"enso-prelude",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2022-02-16 15:58:02 +03:00
|
|
|
name = "async-channel"
|
|
|
|
version = "1.6.1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "2114d64672151c0c5eaa5e131ec84a74f06e1e559830dabba01ca30605d66319"
|
|
|
|
dependencies = [
|
|
|
|
"concurrent-queue",
|
|
|
|
"event-listener",
|
|
|
|
"futures-core",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "async-compression"
|
|
|
|
version = "0.3.14"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "345fd392ab01f746c717b1357165b76f0b67a60192007b234058c9045fdcf695"
|
|
|
|
dependencies = [
|
|
|
|
"flate2",
|
|
|
|
"futures-core",
|
|
|
|
"memchr",
|
|
|
|
"pin-project-lite 0.2.9",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "async-executor"
|
|
|
|
version = "1.4.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "871f9bb5e0a22eeb7e8cf16641feb87c9dc67032ccf8ff49e772eb9941d3a965"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"async-task",
|
2022-02-16 15:58:02 +03:00
|
|
|
"concurrent-queue",
|
|
|
|
"fastrand",
|
|
|
|
"futures-lite",
|
|
|
|
"once_cell",
|
|
|
|
"slab",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-global-executor"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "2.0.4"
|
2022-02-16 15:58:02 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "c290043c9a95b05d45e952fb6383c67bcb61471f60cfa21e890dba6654234f43"
|
2022-02-16 15:58:02 +03:00
|
|
|
dependencies = [
|
|
|
|
"async-channel",
|
|
|
|
"async-executor",
|
|
|
|
"async-io",
|
|
|
|
"async-mutex",
|
|
|
|
"blocking",
|
|
|
|
"futures-lite",
|
|
|
|
"num_cpus",
|
|
|
|
"once_cell",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-io"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "1.7.0"
|
2022-02-16 15:58:02 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "e5e18f61464ae81cde0a23e713ae8fd299580c54d697a35820cfd0625b8b0e07"
|
2022-02-16 15:58:02 +03:00
|
|
|
dependencies = [
|
|
|
|
"concurrent-queue",
|
|
|
|
"futures-lite",
|
|
|
|
"libc",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2022-02-16 15:58:02 +03:00
|
|
|
"once_cell",
|
|
|
|
"parking",
|
|
|
|
"polling",
|
|
|
|
"slab",
|
|
|
|
"socket2 0.4.4",
|
|
|
|
"waker-fn",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-lock"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "2.5.0"
|
2022-02-16 15:58:02 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "e97a171d191782fba31bb902b14ad94e24a68145032b7eedf871ab0bc0d077b6"
|
2022-02-16 15:58:02 +03:00
|
|
|
dependencies = [
|
|
|
|
"event-listener",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-mutex"
|
|
|
|
version = "1.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "479db852db25d9dbf6204e6cb6253698f175c15726470f78af0d918e99d6156e"
|
|
|
|
dependencies = [
|
|
|
|
"event-listener",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-std"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.11.0"
|
2022-02-16 15:58:02 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "52580991739c5cdb36cde8b2a516371c0a3b70dda36d916cc08b82372916808c"
|
2022-02-16 15:58:02 +03:00
|
|
|
dependencies = [
|
|
|
|
"async-channel",
|
|
|
|
"async-global-executor",
|
|
|
|
"async-io",
|
|
|
|
"async-lock",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"crossbeam-utils 0.8.8",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures-channel",
|
2021-11-10 16:36:08 +03:00
|
|
|
"futures-core",
|
|
|
|
"futures-io",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures-lite",
|
|
|
|
"gloo-timers",
|
2021-11-10 16:36:08 +03:00
|
|
|
"kv-log-macro",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
"memchr",
|
|
|
|
"num_cpus",
|
|
|
|
"once_cell",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"pin-project-lite 0.2.9",
|
2021-11-10 16:36:08 +03:00
|
|
|
"pin-utils",
|
|
|
|
"slab",
|
2022-02-16 15:58:02 +03:00
|
|
|
"wasm-bindgen-futures",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "async-stream"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "dad5c83079eae9969be7fadefe640a1c566901f05ff91ab221de4b6f68d9507e"
|
|
|
|
dependencies = [
|
|
|
|
"async-stream-impl",
|
|
|
|
"futures-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-stream-impl"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "10f203db73a71dfa2fb6dd22763990fa26f3d2625a6da2da900d23b87d26be27"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "async-task"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "4.2.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "30696a84d817107fc028e049980e09d5e140e8da8f1caeb17e8e950658a3cea9"
|
2022-02-16 15:58:02 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "async-trait"
|
|
|
|
version = "0.1.53"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ed6aa3524a2dfcf9fe180c51eae2b58738348d819517ceadf95789c51fff7600"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "async_once"
|
|
|
|
version = "0.2.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2ce4f10ea3abcd6617873bae9f91d1c5332b4a778bd9ce34d0cd517474c1de82"
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "atomic-waker"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "065374052e7df7ee4047b1160cca5e1467a12351a40b3da123c870ba0b8eda2a"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "atty"
|
|
|
|
version = "0.2.14"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d9b39be18770d11421cdb1b9947a45dd3f37e93092cbf377614828a319d5fee8"
|
|
|
|
dependencies = [
|
|
|
|
"hermit-abi",
|
|
|
|
"libc",
|
2021-11-10 16:36:08 +03:00
|
|
|
"winapi 0.3.9",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "autocfg"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.1.8"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "0dde43e75fd43e8a1bf86103336bc699aa8d17ad1be60c76c0bdfd4828e19b78"
|
|
|
|
dependencies = [
|
|
|
|
"autocfg 1.1.0",
|
|
|
|
]
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "autocfg"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.1.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "d468802bab17cbc0cc575e9b053f41e72aa36bfa6b7f55e3529ffa43161b97fa"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "aws-config"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "b58e10d03d2180f9fce2fe72ffa007ccf44b4714b127d8429e78c3e55fe345c0"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-http",
|
2022-05-26 05:14:11 +03:00
|
|
|
"aws-sdk-sso",
|
2022-05-23 05:16:04 +03:00
|
|
|
"aws-sdk-sts",
|
|
|
|
"aws-smithy-async",
|
|
|
|
"aws-smithy-client",
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-smithy-http-tower",
|
|
|
|
"aws-smithy-json",
|
|
|
|
"aws-smithy-types",
|
|
|
|
"aws-types",
|
|
|
|
"bytes 1.1.0",
|
2022-05-26 05:14:11 +03:00
|
|
|
"hex",
|
2022-05-23 05:16:04 +03:00
|
|
|
"http",
|
|
|
|
"hyper 0.14.18",
|
2022-05-26 05:14:11 +03:00
|
|
|
"ring",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tower",
|
|
|
|
"tracing",
|
2022-05-26 05:14:11 +03:00
|
|
|
"zeroize",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-endpoint"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "6eadd9ea45f65689fbd088b22a2aaed363582fab5dcd335a1a7317640436952f"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-types",
|
|
|
|
"http",
|
|
|
|
"regex",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-http"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "80fd2c81e2782d1f57a532543524c59b9c32dcc9132a7a2d308864c05b645e98"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-smithy-types",
|
|
|
|
"aws-types",
|
|
|
|
"http",
|
|
|
|
"lazy_static",
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-sdk-s3"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "993422785adde6d8cadd1ef2594591d9dff3326968d5a9f2039d64833a52fbb3"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-endpoint",
|
|
|
|
"aws-http",
|
|
|
|
"aws-sig-auth",
|
|
|
|
"aws-sigv4",
|
|
|
|
"aws-smithy-async",
|
|
|
|
"aws-smithy-client",
|
|
|
|
"aws-smithy-eventstream",
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-smithy-http-tower",
|
|
|
|
"aws-smithy-types",
|
|
|
|
"aws-smithy-xml",
|
|
|
|
"aws-types",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"http",
|
|
|
|
"md5",
|
|
|
|
"tokio-stream",
|
|
|
|
"tower",
|
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "aws-sdk-sso"
|
|
|
|
version = "0.12.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0c856987e02db8c5d81cb97e2a24609b05a6289db3d861c5b7d73081d6ecc70d"
|
|
|
|
dependencies = [
|
|
|
|
"aws-endpoint",
|
|
|
|
"aws-http",
|
|
|
|
"aws-sig-auth",
|
|
|
|
"aws-smithy-async",
|
|
|
|
"aws-smithy-client",
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-smithy-http-tower",
|
|
|
|
"aws-smithy-json",
|
|
|
|
"aws-smithy-types",
|
|
|
|
"aws-types",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"http",
|
|
|
|
"tokio-stream",
|
|
|
|
"tower",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "aws-sdk-sts"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "dbf0a83f4382e47778399d0e0ae38761eee2fbad1d3bdde21358bd00cea46f36"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-endpoint",
|
|
|
|
"aws-http",
|
|
|
|
"aws-sig-auth",
|
|
|
|
"aws-smithy-async",
|
|
|
|
"aws-smithy-client",
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-smithy-http-tower",
|
|
|
|
"aws-smithy-query",
|
|
|
|
"aws-smithy-types",
|
|
|
|
"aws-smithy-xml",
|
|
|
|
"aws-types",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"http",
|
|
|
|
"tower",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-sig-auth"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "27079eb4062be105e44ab4638ade63cf6448c2df5cb093d885faab8082fd5c9d"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-sigv4",
|
|
|
|
"aws-smithy-eventstream",
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-types",
|
|
|
|
"http",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-sigv4"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "a0be4a7223c244f3c57426087204cf66e04d1e73adb62571090613889cf6ee57"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-eventstream",
|
|
|
|
"aws-smithy-http",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"form_urlencoded",
|
|
|
|
"hex",
|
|
|
|
"http",
|
|
|
|
"once_cell",
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"regex",
|
|
|
|
"ring",
|
|
|
|
"time 0.3.9",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-async"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "7cafe7e459caf2e2f834a77062f2c47f7df1956cf3be3060b23bf0721f17e1a4"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"futures-util",
|
|
|
|
"pin-project-lite 0.2.9",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-stream",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-client"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "de133c5629abab72cad7c4eeab522cb9dfa11ab7ace07d051ef7c29bb54fd370"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-async",
|
|
|
|
"aws-smithy-http",
|
|
|
|
"aws-smithy-http-tower",
|
|
|
|
"aws-smithy-types",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"fastrand",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"hyper-rustls 0.22.1",
|
|
|
|
"lazy_static",
|
|
|
|
"pin-project",
|
|
|
|
"pin-project-lite 0.2.9",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tower",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-eventstream"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "03681de08131761ad68e46113d0580d5d7fee03281dadd71f07b206ab08a9998"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-types",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"crc32fast",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-http"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "119f6f903f5c27308c732f6c7e460aee91e083b3229db2b21fa40436fc60eda7"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-eventstream",
|
|
|
|
"aws-smithy-types",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"bytes-utils",
|
|
|
|
"futures-core",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"hyper 0.14.18",
|
2022-05-26 05:14:11 +03:00
|
|
|
"once_cell",
|
2022-05-23 05:16:04 +03:00
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"pin-project",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-26 05:14:11 +03:00
|
|
|
"tokio-util 0.7.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-http-tower"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "991855d24079be0b7485a5753f987f060a153757c7f21729d705f2834366c096"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-http",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"pin-project",
|
|
|
|
"tower",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-json"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "81c96aa965ba386c7206c0913c6cbdfd27cf6b276e8834a7408b67f04994e647"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-types",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-query"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "14ec1e497d5e75d42787c9440bbbed5fcdb02b0bdc41fd8b7fe270449e66deff"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-types",
|
|
|
|
"urlencoding",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-types"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "b470753cf7e2ce6b7c55f66cb1d17576654878cd41d72bd863a38336569543f4"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"itoa 1.0.2",
|
|
|
|
"num-integer",
|
|
|
|
"ryu",
|
|
|
|
"time 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-smithy-xml"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.42.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "d795da895bc0d8a2ba44550ee5ec928af06db8ecdfd0e42b88d046e97e73dd94"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"xmlparser",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aws-types"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "e5641c99c740574f7a7e70c03773f5ead9f9daf2d95ce6c790ddb4747e000bb0"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aws-smithy-async",
|
2022-05-26 05:14:11 +03:00
|
|
|
"aws-smithy-client",
|
|
|
|
"aws-smithy-http",
|
2022-05-23 05:16:04 +03:00
|
|
|
"aws-smithy-types",
|
2022-05-26 05:14:11 +03:00
|
|
|
"http",
|
2022-05-23 05:16:04 +03:00
|
|
|
"rustc_version 0.4.0",
|
|
|
|
"tracing",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "axum"
|
|
|
|
version = "0.5.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ab2504b827a8bef941ba3dd64bdffe9cf56ca182908a147edd6189c95fbcae7d"
|
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"axum-core",
|
|
|
|
"bitflags",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"futures-util",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"itoa 1.0.2",
|
|
|
|
"matchit",
|
|
|
|
"memchr",
|
|
|
|
"mime 0.3.16",
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
"serde",
|
|
|
|
"sync_wrapper",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tower",
|
|
|
|
"tower-http",
|
|
|
|
"tower-layer",
|
|
|
|
"tower-service",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "axum-core"
|
|
|
|
version = "0.2.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "da31c0ed7b4690e2c78fe4b880d21cd7db04a346ebc658b4270251b695437f17"
|
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"futures-util",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"mime 0.3.16",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "backtrace"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.3.65"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "11a17d453482a265fd5f8479f2a3f405566e6ca627837aaddb85af8b1ab8ef61"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"addr2line",
|
2021-11-10 16:36:08 +03:00
|
|
|
"cc",
|
2021-01-25 17:41:20 +03:00
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"libc",
|
|
|
|
"miniz_oxide",
|
2022-05-23 05:16:04 +03:00
|
|
|
"object 0.28.4",
|
2021-01-25 17:41:20 +03:00
|
|
|
"rustc-demangle",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "base64"
|
|
|
|
version = "0.9.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "489d6c0ed21b11d038c31b6ceccca973e65d73ba3bd8ecb9a2babf5546164643"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
"safemem",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "base64"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0b25d992356d2eb0ed82172f5248873db5560c4721f564b13cb5193bda5e668e"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
]
|
|
|
|
|
2022-01-11 15:31:43 +03:00
|
|
|
[[package]]
|
|
|
|
name = "base64"
|
|
|
|
version = "0.11.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b41b7ea54a0c9d92199de89e20e58d49f02f8e699814ef3fdf266f6f748d15c7"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "base64"
|
|
|
|
version = "0.13.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "904dfeac50f3cdaba28fc6f57fdcddb75f49ed61346676a78c4ffe55877802fd"
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "base64ct"
|
|
|
|
version = "1.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8a32fd6af2b5827bce66c29053ba0e7c42b9dcab01835835058558c10851a46b"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bimap"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "783204f24fd7724ea274d327619cfa6a6018047bb0561a68aadff6f56787591b"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 0.1.10",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bincode"
|
|
|
|
version = "1.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b1f45e9417d87227c7a56d22e471c6206462cba514c7590c09aff4cf6d1ddcad"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bit_field"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "dcb6dd1c2376d2e096796e234a70e17e94cc2d5d54ff8ce42b28cef1d0d359a4"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bitflags"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "1.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "block-buffer"
|
|
|
|
version = "0.7.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c0940dc441f31689269e10ac70eb1002a3a1d3ad1390e030043662eb7fe4688b"
|
|
|
|
dependencies = [
|
|
|
|
"block-padding",
|
|
|
|
"byte-tools",
|
|
|
|
"byteorder",
|
|
|
|
"generic-array 0.12.4",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "block-buffer"
|
|
|
|
version = "0.10.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0bf7fe51849ea569fd452f37822f606a5cabb684dc918707a0193fd4664ff324"
|
|
|
|
dependencies = [
|
|
|
|
"generic-array 0.14.5",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "block-padding"
|
|
|
|
version = "0.1.5"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "fa79dedbb091f449f1f39e53edf88d5dbe95f895dae6135a8d7b881fb5af73f5"
|
|
|
|
dependencies = [
|
|
|
|
"byte-tools",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "blocking"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.2.0"
|
2022-02-16 15:58:02 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "c6ccb65d468978a086b69884437ded69a90faab3bbe6e67f242173ea728acccc"
|
2022-02-16 15:58:02 +03:00
|
|
|
dependencies = [
|
|
|
|
"async-channel",
|
|
|
|
"async-task",
|
|
|
|
"atomic-waker",
|
|
|
|
"fastrand",
|
|
|
|
"futures-lite",
|
|
|
|
"once_cell",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "boolinator"
|
|
|
|
version = "2.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cfa8873f51c92e232f9bac4065cddef41b714152812bfc5f7672ba16d6ef8cd9"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bstr"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.2.17"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "ba3569f383e8f1598449f1a423e72e99569137b47740b1da11ef19af3d5c3223"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"memchr",
|
|
|
|
"regex-automata",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2021-11-12 15:56:23 +03:00
|
|
|
[[package]]
|
|
|
|
name = "build-scripts"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"glob",
|
|
|
|
"toml",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bumpalo"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "3.9.1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "a4a45a46ab1f2412e53d3a0ade76ffad2025804294569aae387231a0cd6e0899"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "byte-tools"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e3b5ca7a04898ad4bcd41c90c5285445ff5b791899bb1b0abdd2a2aa791211d7"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "byte-unit"
|
|
|
|
version = "4.0.14"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "95ebf10dda65f19ff0f42ea15572a359ed60d7fc74fdc984d90310937be0014b"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
"utf8-width",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bytecount"
|
|
|
|
version = "0.5.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "be0fdd54b507df8f22012890aadd099979befdba27713c767993f8380112ca7c"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "byteorder"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "1.4.3"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "14c189c53d098945499cdfa7ecc63567cf3886b3332b312a5b4585d8d3a6a610"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bytes"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.4.12"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "206fdffcfa2df7cbe15601ef46c813fce0965eb3286db6b56c583b814b51c81c"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
"iovec",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bytes"
|
|
|
|
version = "0.5.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0e4cec68f03f32e44924783795810fa50a7035d8c8ebe78580ad7e6c703fba38"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bytes"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c4872d67bab6358e59559027aa3b9157c53d9358c51423c17554809a8858e0f8"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bytes-utils"
|
|
|
|
version = "0.1.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1934a3ef9cac8efde4966a92781e77713e1ba329f1d42e446c7d7eba340d8ef1"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"either",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "bzip2"
|
|
|
|
version = "0.4.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6afcd980b5f3a45017c57e57a2fcccbb351cc43a356ce117ef760ef8052b89b0"
|
|
|
|
dependencies = [
|
|
|
|
"bzip2-sys",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bzip2-sys"
|
|
|
|
version = "0.1.11+1.0.8"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "736a955f3fa7875102d57c82b8cac37ec45224a07fd32d58f9f7a186b6cd4cdc"
|
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"libc",
|
|
|
|
"pkg-config",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cache-padded"
|
|
|
|
version = "1.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c1db59621ec70f09c5e9b597b220c7a2b43611f4710dc03ceb8748637775692c"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cached"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.34.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "aadf76ddea74bab35ebeb8f1eb115b9bc04eaee42d8acc0d5f477dee6b176c9a"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
2022-05-26 05:14:11 +03:00
|
|
|
"async_once",
|
2022-05-23 05:16:04 +03:00
|
|
|
"cached_proc_macro",
|
|
|
|
"cached_proc_macro_types",
|
|
|
|
"futures 0.3.21",
|
2022-05-26 05:14:11 +03:00
|
|
|
"hashbrown 0.12.1",
|
|
|
|
"lazy_static",
|
2022-05-23 05:16:04 +03:00
|
|
|
"once_cell",
|
2022-05-26 05:14:11 +03:00
|
|
|
"thiserror",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cached_proc_macro"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.12.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "bce0f37f9b77c6b93cdf3f060c89adca303d2ab052cacb3c3d1ab543e8cecd2f"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"cached_proc_macro_types",
|
|
|
|
"darling",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cached_proc_macro_types"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3a4f925191b4367301851c6d99b09890311d74b0d43f274c0b34c86d308a3663"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cast"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.2.7"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "4c24dab4283a142afa2fdca129b80ad2c6284e073930f964c3a1293c225ee39a"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"rustc_version 0.4.0",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cc"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.0.73"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "2fff2a6927b3bb87f9595d67196a70493f627687a71d87a0d692242c33f58c11"
|
2022-05-26 05:14:11 +03:00
|
|
|
dependencies = [
|
|
|
|
"jobserver",
|
|
|
|
]
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cfg-if"
|
|
|
|
version = "0.1.10"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4785bdd1c96b2a846b2bd7cc02e86b6b3dbf14e7e53446c4f54c92a361040822"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cfg-if"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "chrono"
|
|
|
|
version = "0.4.19"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "670ad68c9088c2a963aaa298cb369688cf3f9465ce5e2d4ca10e6e0098a1ce73"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
"serde",
|
2022-05-23 05:16:04 +03:00
|
|
|
"time 0.1.44",
|
2021-11-10 16:36:08 +03:00
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cipher"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7ee52072ec15386f770805afd189a01c8841be8696bed250fa2f13c4c0d6dfb7"
|
|
|
|
dependencies = [
|
|
|
|
"generic-array 0.14.5",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "clap"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "2.34.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "a0610544180c38b88101fecf2dd634b174a62eef6946f84dfc6a7127512b381c"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
2022-05-23 05:16:04 +03:00
|
|
|
"textwrap 0.11.0",
|
2021-01-25 17:41:20 +03:00
|
|
|
"unicode-width",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "clap"
|
|
|
|
version = "3.1.18"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d2dbdf4bdacb33466e854ce889eee8dfd5729abf7ccd7664d0a2d60cd384440b"
|
|
|
|
dependencies = [
|
|
|
|
"atty",
|
|
|
|
"bitflags",
|
|
|
|
"clap_derive",
|
|
|
|
"clap_lex",
|
|
|
|
"indexmap",
|
|
|
|
"lazy_static",
|
|
|
|
"strsim",
|
|
|
|
"termcolor",
|
|
|
|
"terminal_size",
|
|
|
|
"textwrap 0.15.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "clap_derive"
|
|
|
|
version = "3.1.18"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "25320346e922cffe59c0bbc5410c8d8784509efb321488971081313cb1e1a33c"
|
|
|
|
dependencies = [
|
|
|
|
"heck 0.4.0",
|
|
|
|
"proc-macro-error",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "clap_lex"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a37c35f1112dad5e6e0b1adaff798507497a18fceeb30cceb3bae7d1427b9213"
|
|
|
|
dependencies = [
|
|
|
|
"os_str_bytes",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cloudabi"
|
|
|
|
version = "0.0.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ddfc5b9aa5d4507acaf872de71051dfd0e309860e88966e1051e462a077aac4f"
|
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "code-builder"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-prelude",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2022-05-23 05:16:04 +03:00
|
|
|
name = "colored"
|
|
|
|
version = "2.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b3616f750b84d8f0de8a58bda93e08e2a81ad3f523089b05f1dffecab48c6cbd"
|
|
|
|
dependencies = [
|
|
|
|
"atty",
|
|
|
|
"lazy_static",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "combine"
|
|
|
|
version = "3.8.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "da3da6baa321ec19e1cc41d31bf599f00c783d0517095cdaf0332e3fe8d20680"
|
|
|
|
dependencies = [
|
|
|
|
"ascii",
|
|
|
|
"byteorder",
|
|
|
|
"either",
|
|
|
|
"memchr",
|
|
|
|
"unreachable",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "concurrent-queue"
|
|
|
|
version = "1.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "30ed07550be01594c6026cff2a1d7fe9c8f683caa798e12b68694ac9e88286a3"
|
|
|
|
dependencies = [
|
|
|
|
"cache-padded",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "config-reader"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
|
|
|
"serde",
|
|
|
|
"serde_yaml",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "console"
|
|
|
|
version = "0.15.0"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "a28b32d32ca44b70c3e4acd7db1babf555fa026e385fb95f18028f88848b3c31"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"encode_unicode",
|
|
|
|
"libc",
|
|
|
|
"once_cell",
|
|
|
|
"regex",
|
|
|
|
"terminal_size",
|
|
|
|
"unicode-width",
|
2021-11-10 16:36:08 +03:00
|
|
|
"winapi 0.3.9",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
2022-05-23 05:16:04 +03:00
|
|
|
name = "console-api"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.3.0"
|
2022-02-16 15:58:02 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "06c5fd425783d81668ed68ec98408a80498fb4ae2fd607797539e1a9dfa3618f"
|
2022-02-16 15:58:02 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"prost",
|
|
|
|
"prost-types",
|
|
|
|
"tonic",
|
|
|
|
"tracing-core",
|
2022-02-16 15:58:02 +03:00
|
|
|
]
|
|
|
|
|
2021-11-12 15:56:23 +03:00
|
|
|
[[package]]
|
2022-05-23 05:16:04 +03:00
|
|
|
name = "console-subscriber"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.1.6"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "31432bc31ff8883bf6a693a79371862f73087822470c82d6a1ec778781ee3978"
|
2021-11-12 15:56:23 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"console-api",
|
|
|
|
"crossbeam-channel",
|
|
|
|
"crossbeam-utils 0.8.8",
|
|
|
|
"futures 0.3.21",
|
|
|
|
"hdrhistogram",
|
|
|
|
"humantime 2.1.0",
|
|
|
|
"prost-types",
|
2021-11-12 15:56:23 +03:00
|
|
|
"serde",
|
2022-05-23 05:16:04 +03:00
|
|
|
"serde_json",
|
|
|
|
"thread_local",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-stream",
|
|
|
|
"tonic",
|
|
|
|
"tracing",
|
|
|
|
"tracing-core",
|
|
|
|
"tracing-subscriber",
|
2021-11-12 15:56:23 +03:00
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
|
|
|
name = "console_error_panic_hook"
|
|
|
|
version = "0.1.7"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
source = "git+https://github.com/enso-org/console_error_panic_hook#cdd73b81709475104b9ebfe6271c6914ff71b7b2"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2022-04-12 20:39:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "const_format"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.2.23"
|
2022-04-12 20:39:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "0936ffe6d0c8d6a51b3b0a73b2acbe925d786f346cf45bfddc8341d79fb7dc8a"
|
2022-04-12 20:39:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"const_format_proc_macros",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "const_format_proc_macros"
|
|
|
|
version = "0.2.22"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ef196d5d972878a48da7decb7686eded338b4858fbabeed513d63a7c98b2b82d"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"unicode-xid",
|
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "constant_time_eq"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "245097e9a4535ee1e3e3931fcfcd55a796a44c643e8596ff6566d68f09b87bbc"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "convert_case"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6245d59a3e82a7fc217c5828a6692dbc6dfb63a0c8c90495621f7b9d79704a0e"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "convert_case"
|
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fb4a24b1aaf0fd0ce8b45161144d6f42cd91677fd5940fd431183eb023b3a2b8"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "core-foundation"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.9.3"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "194a7a9e6de53fa55116934067c844d9d749312f75c6f6d0980e8c252f8c2146"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "core-foundation-sys"
|
|
|
|
version = "0.8.3"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "5827cebf4670468b8772dd191856768aedcb1b0278a04f989f7766351917b9dc"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "cpufeatures"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "59a6001667ab124aebae2a495118e11d30984c3a653e99d86d58971708cf5e4b"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2021-05-14 15:08:39 +03:00
|
|
|
[[package]]
|
|
|
|
name = "crc32fast"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.3.2"
|
2021-05-14 15:08:39 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "b540bd8bc810d3885c6ea91e2018302f68baba2129ab3e88f32389ee9370880d"
|
2021-05-14 15:08:39 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "criterion"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.5"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "1604dafd25fba2fe2d5895a9da139f8dc9b319a5fe5354ca137cbbce4e178d10"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"atty",
|
|
|
|
"cast",
|
2022-05-23 05:16:04 +03:00
|
|
|
"clap 2.34.0",
|
2021-01-25 17:41:20 +03:00
|
|
|
"criterion-plot",
|
|
|
|
"csv",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itertools 0.10.3",
|
2021-01-25 17:41:20 +03:00
|
|
|
"lazy_static",
|
|
|
|
"num-traits",
|
|
|
|
"oorandom",
|
|
|
|
"plotters",
|
|
|
|
"rayon",
|
|
|
|
"regex",
|
|
|
|
"serde",
|
|
|
|
"serde_cbor",
|
|
|
|
"serde_derive",
|
|
|
|
"serde_json",
|
|
|
|
"tinytemplate",
|
|
|
|
"walkdir",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "criterion-plot"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.4.4"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "d00996de9f2f7559f7f4dc286073197f83e92256a59ed395f9aac01fe717da57"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"cast",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itertools 0.10.3",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-channel"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.5.4"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "5aaa7bd5fb665c6864b5f963dd9097905c54125909c7aa94c9e18507cdbe6c53"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"crossbeam-utils 0.8.8",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-deque"
|
|
|
|
version = "0.8.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "6455c0ca19f0d2fbf751b908d5c55c1f5cbc65e03c4225427254b46890bdde1e"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
2022-02-16 15:58:02 +03:00
|
|
|
"crossbeam-epoch",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"crossbeam-utils 0.8.8",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-epoch"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.9.8"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "1145cf131a2c6ba0615079ab6a638f7e1973ac9c2634fcbeaaad6114246efe8c"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-01-25 17:41:20 +03:00
|
|
|
"cfg-if 1.0.0",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"crossbeam-utils 0.8.8",
|
2021-01-25 17:41:20 +03:00
|
|
|
"lazy_static",
|
2022-02-16 15:58:02 +03:00
|
|
|
"memoffset",
|
2021-01-25 17:41:20 +03:00
|
|
|
"scopeguard",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-utils"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.7.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c3c7c73a2d1e9fc0886a08b93e98eb643461230d5f1925e4036204d5f2e261a8"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"cfg-if 0.1.10",
|
|
|
|
"lazy_static",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-utils"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.8.8"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "0bf124c720b7686e3c2663cf54062ab0f68a88af2fb6a030e87e30bf721fcb38"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"lazy_static",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "crypto-common"
|
|
|
|
version = "0.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "57952ca27b5e3606ff4dd79b0020231aaf9d6aa76dc05fd30137538c50bd3ce8"
|
|
|
|
dependencies = [
|
|
|
|
"generic-array 0.14.5",
|
|
|
|
"typenum",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "csv"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "1.1.6"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "22813a6dc45b335f9bade10bf7271dc477e81113e89eb251a0bc2a8a81c536e1"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"bstr",
|
|
|
|
"csv-core",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itoa 0.4.8",
|
2021-01-25 17:41:20 +03:00
|
|
|
"ryu",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "csv-core"
|
|
|
|
version = "0.1.10"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2b2466559f260f48ad25fe6317b3c8dac77b5bdb5763ac7d9d6103530663bc90"
|
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ct-logs"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c1a816186fa68d9e426e3cb4ae4dff1fcd8e4a2c34b781bf7a822574a0d0aac8"
|
|
|
|
dependencies = [
|
|
|
|
"sct 0.6.1",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ctor"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.1.22"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "f877be4f7c9f246b183111634f75baa039715e3f46ce860677d3b19a69fb229c"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "darling"
|
|
|
|
version = "0.13.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a01d95850c592940db9b8194bc39f4bc0e89dee5c4265e4b1807c34a9aba453c"
|
|
|
|
dependencies = [
|
|
|
|
"darling_core",
|
|
|
|
"darling_macro",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "darling_core"
|
|
|
|
version = "0.13.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "859d65a907b6852c9361e3185c862aae7fafd2887876799fa55f5f99dc40d610"
|
|
|
|
dependencies = [
|
|
|
|
"fnv",
|
|
|
|
"ident_case",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"strsim",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "darling_macro"
|
|
|
|
version = "0.13.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9c972679f83bdf9c42bd905396b6c3588a843a17f0f16dfcfa3e2c5d57441835"
|
|
|
|
dependencies = [
|
|
|
|
"darling_core",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "data-encoding"
|
|
|
|
version = "2.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3ee2393c4a91429dffb4bedf19f4d6abf27d8a732c8ce4980305d782e5426d57"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "deadpool"
|
|
|
|
version = "0.9.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "421fe0f90f2ab22016f32a9881be5134fdd71c65298917084b0c7477cbc3856e"
|
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"deadpool-runtime",
|
|
|
|
"num_cpus",
|
|
|
|
"retain_mut",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "deadpool-runtime"
|
|
|
|
version = "0.1.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "eaa37046cc0f6c3cc6090fbdbf73ef0b8ef4cfcc37f6befc0020f63e8cf121e1"
|
|
|
|
|
2022-04-14 13:37:40 +03:00
|
|
|
[[package]]
|
|
|
|
name = "debug-scene-component-group"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
2022-05-24 10:48:19 +03:00
|
|
|
"enso-text",
|
2022-04-14 13:37:40 +03:00
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-list-view",
|
2022-05-17 16:52:08 +03:00
|
|
|
"ensogl-scroll-area",
|
2022-05-12 12:30:00 +03:00
|
|
|
"ensogl-selector",
|
2022-04-14 13:37:40 +03:00
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"ide-view-component-group",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2022-05-24 10:48:19 +03:00
|
|
|
[[package]]
|
|
|
|
name = "debug-scene-icons"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ide-view-component-group",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "debug-scene-interface"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ast",
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"ide-view",
|
|
|
|
"parser",
|
|
|
|
"span-tree",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2021-11-30 14:27:50 +03:00
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "debug-scene-visualization"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"ide-view",
|
|
|
|
"js-sys",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"serde_json",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "derivative"
|
2021-05-14 15:08:39 +03:00
|
|
|
version = "2.2.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-05-14 15:08:39 +03:00
|
|
|
checksum = "fcc3dd5e9e9c0b295d6e1e4d811fb6f157d5ffd784b8d202fc62eac8035a770b"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-05 18:55:55 +03:00
|
|
|
"syn",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "derive_more"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.99.17"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "4fb810d30a7c1953f91334de7244731fc3f3c10d7fe163338a35b9f640960321"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"convert_case 0.4.0",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2022-02-16 15:58:02 +03:00
|
|
|
"rustc_version 0.4.0",
|
2021-11-05 18:55:55 +03:00
|
|
|
"syn",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "difference"
|
|
|
|
version = "2.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "524cbf6897b527295dff137cec09ecf3a05f4fddffd7dfcd1585403449e74198"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "digest"
|
|
|
|
version = "0.8.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f3d0c8c8752312f9713efd397ff63acb9f85585afbf179282e720e7704954dd5"
|
|
|
|
dependencies = [
|
|
|
|
"generic-array 0.12.4",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "digest"
|
|
|
|
version = "0.10.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f2fb860ca6fafa5552fb6d0e816a69c8e49f0908bf524e30a90d97c85892d506"
|
|
|
|
dependencies = [
|
|
|
|
"block-buffer 0.10.2",
|
|
|
|
"crypto-common",
|
2022-05-26 05:14:11 +03:00
|
|
|
"subtle",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "dirs"
|
|
|
|
version = "4.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ca3aa72a6f96ea37bbc5aa912f6788242832f75369bdfdadcb0e38423f100059"
|
|
|
|
dependencies = [
|
|
|
|
"dirs-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "dirs-sys"
|
|
|
|
version = "0.3.7"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1b1d1d91c932ef41c0f2663aa8b0ca0342d444d842c06914aa0a7e352d0bada6"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"redox_users",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "doc-comment"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fea41bba32d969b513997752735605054bc0dfa92b4c56bf1189f2e174be7a10"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "double-representation"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ast",
|
|
|
|
"engine-protocol",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
2022-06-01 21:01:16 +03:00
|
|
|
"enso-profiler",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-10 16:36:08 +03:00
|
|
|
"failure",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itertools 0.10.3",
|
2021-11-10 16:36:08 +03:00
|
|
|
"parser",
|
|
|
|
"regex",
|
|
|
|
"serde",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "downcast"
|
|
|
|
version = "0.10.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4bb454f0228b18c7f4c3b0ebbee346ed9c52e7443b0999cd543ff3571205701d"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "either"
|
|
|
|
version = "1.6.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e78d4f1cc4ae33bbfc157ed5d5a5ef3bc29227303d595861deb238fcec4e9457"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enclose"
|
|
|
|
version = "1.1.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1056f553da426e9c025a662efa48b52e62e0a3a7648aa2d15aeaaf7f0d329357"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "encode_unicode"
|
|
|
|
version = "0.3.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a357d28ed41a50f9c765dbfe56cbc04a64e53e5fc58ba79fbc34c10ef3df831f"
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "encoding_rs"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.8.31"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "9852635589dc9f9ea1b6fe9f05b50ef208c85c834a562f0c6abb1c475736ec2b"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"cfg-if 1.0.0",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "engine-protocol"
|
|
|
|
version = "0.1.0"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 0.5.6",
|
|
|
|
"chrono",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-build-utilities",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
|
|
|
"enso-shapely",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-web",
|
2021-11-10 16:36:08 +03:00
|
|
|
"failure",
|
|
|
|
"flatbuffers",
|
|
|
|
"flatc-rust",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
2021-11-10 16:36:08 +03:00
|
|
|
"hex",
|
|
|
|
"json-rpc",
|
|
|
|
"mockall",
|
2022-05-23 05:16:04 +03:00
|
|
|
"reqwest 0.10.10",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"sha3",
|
2022-05-26 05:14:11 +03:00
|
|
|
"strum",
|
|
|
|
"strum_macros",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2022-05-26 05:14:11 +03:00
|
|
|
"zip 0.5.13",
|
2021-11-10 16:36:08 +03:00
|
|
|
"zip-extensions",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-12 15:56:23 +03:00
|
|
|
name = "enso-automata"
|
|
|
|
version = "0.2.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"enso-prelude",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-build"
|
|
|
|
version = "0.1.0"
|
2022-06-14 09:38:56 +03:00
|
|
|
source = "git+https://github.com/enso-org/ci-build?branch=develop#75db499c249c91b55b5c801632ac33291619076c"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"async-compression",
|
|
|
|
"async-trait",
|
|
|
|
"aws-config",
|
|
|
|
"aws-sdk-s3",
|
|
|
|
"byte-unit",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"cached",
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"chrono",
|
|
|
|
"clap 3.1.18",
|
|
|
|
"console-subscriber",
|
|
|
|
"derivative",
|
2022-06-14 03:28:04 +03:00
|
|
|
"derive_more",
|
2022-05-23 05:16:04 +03:00
|
|
|
"dirs",
|
|
|
|
"filetime",
|
|
|
|
"flate2",
|
|
|
|
"flume",
|
|
|
|
"fs_extra",
|
|
|
|
"futures 0.3.21",
|
|
|
|
"futures-util",
|
|
|
|
"glob",
|
|
|
|
"heck 0.4.0",
|
|
|
|
"humantime 2.1.0",
|
|
|
|
"ide-ci",
|
|
|
|
"ifmt",
|
|
|
|
"indexmap",
|
|
|
|
"indicatif",
|
|
|
|
"itertools 0.10.3",
|
|
|
|
"lazy_static",
|
|
|
|
"log 0.4.17",
|
|
|
|
"mime 0.3.16",
|
2022-05-26 05:14:11 +03:00
|
|
|
"nix",
|
2022-05-23 05:16:04 +03:00
|
|
|
"octocrab",
|
|
|
|
"ouroboros",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"paste 1.0.7",
|
2022-05-23 05:16:04 +03:00
|
|
|
"path-absolutize",
|
|
|
|
"pin-project",
|
|
|
|
"platforms",
|
|
|
|
"port_check",
|
|
|
|
"pretty_env_logger",
|
|
|
|
"pulldown-cmark",
|
|
|
|
"rand 0.8.5",
|
|
|
|
"regex",
|
|
|
|
"reqwest 0.11.10",
|
|
|
|
"scopeguard",
|
|
|
|
"semver 1.0.9",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"serde_yaml",
|
|
|
|
"shrinkwraprs 0.3.0",
|
2022-05-26 05:14:11 +03:00
|
|
|
"snafu",
|
|
|
|
"strum",
|
2022-05-23 05:16:04 +03:00
|
|
|
"sysinfo",
|
|
|
|
"tar",
|
|
|
|
"tempfile",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"toml",
|
|
|
|
"tracing",
|
|
|
|
"tracing-subscriber",
|
|
|
|
"unicase 2.6.0",
|
|
|
|
"url 2.2.2",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 1.1.0",
|
2022-05-23 05:16:04 +03:00
|
|
|
"walkdir",
|
|
|
|
"which",
|
|
|
|
"whoami",
|
2022-05-26 05:14:11 +03:00
|
|
|
"zip 0.6.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-build-cli"
|
|
|
|
version = "0.1.0"
|
2022-06-14 09:38:56 +03:00
|
|
|
source = "git+https://github.com/enso-org/ci-build?branch=develop#75db499c249c91b55b5c801632ac33291619076c"
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"byte-unit",
|
|
|
|
"clap 3.1.18",
|
|
|
|
"derivative",
|
|
|
|
"enso-build",
|
|
|
|
"futures 0.3.21",
|
|
|
|
"futures-util",
|
|
|
|
"humantime 2.1.0",
|
|
|
|
"ide-ci",
|
|
|
|
"octocrab",
|
|
|
|
"strum",
|
|
|
|
"tempfile",
|
|
|
|
"tokio 1.19.2",
|
|
|
|
"tracing",
|
|
|
|
"tracing-subscriber",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
2021-11-12 15:56:23 +03:00
|
|
|
name = "enso-build-utilities"
|
|
|
|
version = "0.1.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2021-11-12 15:56:23 +03:00
|
|
|
"path-clean",
|
2022-05-23 05:16:04 +03:00
|
|
|
"reqwest 0.10.10",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-build3"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-build",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"enso-build-cli",
|
2022-05-23 05:16:04 +03:00
|
|
|
"ide-ci",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-callback"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-prelude",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-config"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2021-11-12 15:56:23 +03:00
|
|
|
"config-reader",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
|
|
|
"ensogl",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"semver 1.0.9",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-25 13:45:42 +03:00
|
|
|
name = "enso-data-structures"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.2.0"
|
|
|
|
dependencies = [
|
|
|
|
"criterion",
|
|
|
|
"enso-prelude",
|
2022-05-17 06:13:20 +03:00
|
|
|
"failure",
|
2021-10-30 16:04:07 +03:00
|
|
|
"itertools 0.9.0",
|
|
|
|
"rustversion",
|
|
|
|
"serde",
|
|
|
|
"typenum",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-debug-api"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"derivative",
|
2022-06-01 21:01:16 +03:00
|
|
|
"futures 0.3.21",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-debug-scene"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2022-04-14 13:37:40 +03:00
|
|
|
"debug-scene-component-group",
|
2022-05-24 10:48:19 +03:00
|
|
|
"debug-scene-icons",
|
2021-11-30 14:27:50 +03:00
|
|
|
"debug-scene-interface",
|
|
|
|
"debug-scene-visualization",
|
|
|
|
]
|
|
|
|
|
2022-03-10 06:47:00 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-formatter"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"regex",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-frp"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
|
|
|
"enso-callback",
|
|
|
|
"enso-generics",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
2022-03-23 14:06:25 +03:00
|
|
|
"enso-profiler",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-web",
|
2021-11-10 16:36:08 +03:00
|
|
|
"keyboard-types",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"unicode-segmentation",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-generics"
|
|
|
|
version = "0.2.0"
|
|
|
|
dependencies = [
|
|
|
|
"nalgebra 0.21.1",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2021-11-16 12:04:56 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-gui"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"analytics",
|
|
|
|
"ast",
|
|
|
|
"bimap",
|
|
|
|
"console_error_panic_hook",
|
|
|
|
"double-representation",
|
|
|
|
"engine-protocol",
|
|
|
|
"enso-callback",
|
|
|
|
"enso-config",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"enso-debug-api",
|
2021-11-30 14:27:50 +03:00
|
|
|
"enso-debug-scene",
|
2021-11-16 12:04:56 +03:00
|
|
|
"enso-frp",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
2022-02-10 20:24:29 +03:00
|
|
|
"enso-profiler",
|
2021-11-16 12:04:56 +03:00
|
|
|
"enso-shapely",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-16 12:04:56 +03:00
|
|
|
"enso-web",
|
|
|
|
"ensogl",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-component",
|
2021-11-16 12:04:56 +03:00
|
|
|
"ensogl-drop-manager",
|
|
|
|
"ensogl-examples",
|
2022-01-14 15:40:03 +03:00
|
|
|
"ensogl-hardcoded-theme",
|
2021-11-16 12:04:56 +03:00
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"failure",
|
|
|
|
"flo_stream",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
2021-11-16 12:04:56 +03:00
|
|
|
"fuzzly",
|
|
|
|
"ide-view",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itertools 0.10.3",
|
2021-11-16 12:04:56 +03:00
|
|
|
"js-sys",
|
|
|
|
"json-rpc",
|
|
|
|
"mockall",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"parser",
|
|
|
|
"regex",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"semver 1.0.9",
|
2021-11-16 12:04:56 +03:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"sha3",
|
|
|
|
"span-tree",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2021-11-16 12:04:56 +03:00
|
|
|
"wasm-bindgen",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"wasm-bindgen-futures",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-16 12:04:56 +03:00
|
|
|
"web-sys",
|
|
|
|
"websocket",
|
|
|
|
]
|
|
|
|
|
2022-02-11 15:19:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-integration-test"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2022-02-22 19:43:37 +03:00
|
|
|
"approx 0.5.1",
|
2022-05-27 14:47:44 +03:00
|
|
|
"engine-protocol",
|
2022-02-11 15:19:02 +03:00
|
|
|
"enso-frp",
|
|
|
|
"enso-gui",
|
|
|
|
"enso-prelude",
|
2022-04-04 18:55:55 +03:00
|
|
|
"enso-shortcuts",
|
2022-02-11 15:19:02 +03:00
|
|
|
"enso-web",
|
|
|
|
"ensogl",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"wasm-bindgen-test",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-logger"
|
|
|
|
version = "0.3.1"
|
|
|
|
dependencies = [
|
2021-11-05 18:55:55 +03:00
|
|
|
"enso-prelude",
|
|
|
|
"enso-shapely",
|
2021-10-30 16:04:07 +03:00
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-macro-utils"
|
|
|
|
version = "0.2.0"
|
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-05 18:55:55 +03:00
|
|
|
"syn",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-optics"
|
|
|
|
version = "0.2.0"
|
|
|
|
dependencies = [
|
2021-11-05 18:55:55 +03:00
|
|
|
"enso-prelude",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-17 06:13:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-parser"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-data-structures",
|
|
|
|
"enso-parser-syntax-tree-builder",
|
|
|
|
"enso-parser-syntax-tree-visitor",
|
|
|
|
"enso-prelude",
|
|
|
|
"enso-shapely-macros",
|
|
|
|
"enso-types",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-parser-syntax-tree-builder"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-macro-utils",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-parser-syntax-tree-visitor"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-macro-utils",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-prelude"
|
|
|
|
version = "0.2.6"
|
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
2022-06-03 20:18:20 +03:00
|
|
|
"assert_approx_eq",
|
2021-10-30 16:04:07 +03:00
|
|
|
"backtrace",
|
|
|
|
"boolinator",
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"colored",
|
|
|
|
"derivative",
|
|
|
|
"derive_more",
|
|
|
|
"enclose",
|
2021-11-05 18:55:55 +03:00
|
|
|
"enso-shapely",
|
2021-10-30 16:04:07 +03:00
|
|
|
"failure",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
2021-11-05 18:55:55 +03:00
|
|
|
"ifmt",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itertools 0.10.3",
|
2021-10-30 16:04:07 +03:00
|
|
|
"lazy_static",
|
|
|
|
"nalgebra 0.26.2",
|
2021-11-05 18:55:55 +03:00
|
|
|
"num",
|
2021-10-30 16:04:07 +03:00
|
|
|
"object 0.24.0",
|
2022-04-14 20:58:53 +03:00
|
|
|
"paste 1.0.7",
|
2021-10-30 16:04:07 +03:00
|
|
|
"serde",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde_json",
|
|
|
|
"shrinkwraprs 0.3.0",
|
2022-02-16 15:58:02 +03:00
|
|
|
"smallvec 1.8.0",
|
2022-05-17 06:13:20 +03:00
|
|
|
"tracing",
|
|
|
|
"tracing-subscriber",
|
|
|
|
"tracing-wasm",
|
2021-10-30 16:04:07 +03:00
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-05 18:55:55 +03:00
|
|
|
"weak-table",
|
2021-10-30 16:04:07 +03:00
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2022-02-10 20:24:29 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-profiler"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-profiler-macros",
|
2022-03-04 01:23:27 +03:00
|
|
|
"enso-web",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
2022-02-28 12:55:56 +03:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2022-02-10 20:24:29 +03:00
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2022-02-28 12:55:56 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-profiler-data"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2022-05-03 20:54:48 +03:00
|
|
|
"derivative",
|
2022-04-11 16:08:09 +03:00
|
|
|
"enso-prelude",
|
2022-02-28 12:55:56 +03:00
|
|
|
"enso-profiler",
|
|
|
|
"futures 0.3.21",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
]
|
|
|
|
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-profiler-enso-data"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"chrono",
|
|
|
|
"csv",
|
|
|
|
"enso-profiler",
|
|
|
|
"enso-profiler-data",
|
|
|
|
"ensogl-core",
|
2022-05-03 20:54:48 +03:00
|
|
|
"json-rpc",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2022-03-04 01:23:27 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-profiler-flame-graph"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-profiler",
|
|
|
|
"enso-profiler-data",
|
|
|
|
"futures 0.3.21",
|
|
|
|
]
|
|
|
|
|
2022-02-10 20:24:29 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-profiler-macros"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2022-02-10 20:24:29 +03:00
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-shapely"
|
|
|
|
version = "0.2.0"
|
|
|
|
dependencies = [
|
|
|
|
"derivative",
|
2021-11-05 18:55:55 +03:00
|
|
|
"enso-prelude",
|
|
|
|
"enso-shapely-macros",
|
2021-10-30 16:04:07 +03:00
|
|
|
"paste 0.1.18",
|
|
|
|
"rustversion",
|
2021-11-10 16:36:08 +03:00
|
|
|
"shrinkwraprs 0.3.0",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "enso-shapely-macros"
|
|
|
|
version = "0.2.1"
|
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
|
|
|
"boolinator",
|
2021-11-05 18:55:55 +03:00
|
|
|
"enso-macro-utils",
|
2021-10-30 16:04:07 +03:00
|
|
|
"itertools 0.8.2",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-05 18:55:55 +03:00
|
|
|
"syn",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "enso-shortcuts"
|
|
|
|
version = "0.1.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-automata",
|
|
|
|
"enso-frp",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-web",
|
2021-11-10 16:36:08 +03:00
|
|
|
"js-sys",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-11-25 13:45:42 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-text"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-prelude",
|
|
|
|
"enso-types",
|
|
|
|
"serde",
|
|
|
|
"xi-rope",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "enso-types"
|
2021-10-30 16:04:07 +03:00
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"num-traits",
|
2022-04-14 20:58:53 +03:00
|
|
|
"paste 1.0.7",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2021-11-12 15:56:23 +03:00
|
|
|
[[package]]
|
|
|
|
name = "enso-web"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"async-std",
|
|
|
|
"console_error_panic_hook",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"enso-debug-api",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
|
|
|
"failure",
|
|
|
|
"gloo-timers",
|
|
|
|
"js-sys",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-12 15:56:23 +03:00
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "ensogl"
|
2021-10-30 16:04:07 +03:00
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-text",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2022-03-16 21:02:47 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-button"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-12 15:56:23 +03:00
|
|
|
name = "ensogl-component"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.1.0"
|
2021-11-30 14:27:50 +03:00
|
|
|
dependencies = [
|
2022-03-16 21:02:47 +03:00
|
|
|
"ensogl-button",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-drop-down-menu",
|
|
|
|
"ensogl-drop-manager",
|
|
|
|
"ensogl-file-browser",
|
2022-03-04 01:23:27 +03:00
|
|
|
"ensogl-flame-graph",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-label",
|
|
|
|
"ensogl-list-view",
|
|
|
|
"ensogl-scroll-area",
|
|
|
|
"ensogl-scrollbar",
|
|
|
|
"ensogl-selector",
|
|
|
|
"ensogl-shadow",
|
|
|
|
"ensogl-text",
|
|
|
|
"ensogl-toggle-button",
|
2022-05-03 12:40:27 +03:00
|
|
|
"ensogl-tooltip",
|
2021-11-30 14:27:50 +03:00
|
|
|
]
|
2021-10-30 16:04:07 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "ensogl-core"
|
|
|
|
version = "0.1.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"Inflector",
|
|
|
|
"bit_field",
|
|
|
|
"code-builder",
|
|
|
|
"console_error_panic_hook",
|
|
|
|
"enso-callback",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"enso-debug-api",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-frp",
|
|
|
|
"enso-generics",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-optics",
|
|
|
|
"enso-prelude",
|
2022-03-15 05:12:39 +03:00
|
|
|
"enso-profiler",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-shapely",
|
|
|
|
"enso-shortcuts",
|
|
|
|
"enso-types",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-web",
|
2021-11-10 16:36:08 +03:00
|
|
|
"ensogl-text-embedded-fonts",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"enum_dispatch",
|
|
|
|
"failure",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itertools 0.10.3",
|
2021-11-10 16:36:08 +03:00
|
|
|
"js-sys",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"num-traits",
|
|
|
|
"num_enum",
|
|
|
|
"rustc-hash",
|
2022-05-23 05:16:04 +03:00
|
|
|
"semver 1.0.9",
|
2022-04-19 14:30:29 +03:00
|
|
|
"serde",
|
2021-11-10 16:36:08 +03:00
|
|
|
"shrinkwraprs 0.3.0",
|
2022-02-16 15:58:02 +03:00
|
|
|
"smallvec 1.8.0",
|
2021-01-25 17:41:20 +03:00
|
|
|
"typenum",
|
2021-11-10 16:36:08 +03:00
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-10 16:36:08 +03:00
|
|
|
"web-sys",
|
2021-11-12 15:56:23 +03:00
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-drop-down-menu"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-list-view",
|
|
|
|
"ensogl-text",
|
|
|
|
]
|
|
|
|
|
2021-11-12 15:56:23 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-drop-manager"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
|
|
|
"enso-web",
|
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-futures",
|
2021-11-12 15:56:23 +03:00
|
|
|
"web-sys",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-30 14:27:50 +03:00
|
|
|
name = "ensogl-example-animation"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.1.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-frp",
|
|
|
|
"enso-prelude",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-text-msdf-sys",
|
2021-11-30 14:27:50 +03:00
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-complex-shape-system"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2022-03-30 05:50:55 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-custom-shape-system"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"enso-profiler",
|
|
|
|
"ensogl-core",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-dom-symbols"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
2021-11-10 16:36:08 +03:00
|
|
|
"nalgebra 0.26.2",
|
2021-11-30 14:27:50 +03:00
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-drop-manager"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"enso-prelude",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-drop-manager",
|
2021-01-25 17:41:20 +03:00
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-futures",
|
2021-11-30 14:27:50 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-easing-animator"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
|
|
|
"js-sys",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"wasm-bindgen",
|
2021-11-10 16:36:08 +03:00
|
|
|
"web-sys",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-30 14:27:50 +03:00
|
|
|
name = "ensogl-example-glyph-system"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-text",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-list-view"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
2021-11-30 14:27:50 +03:00
|
|
|
"enso-text",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-list-view",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-mouse-events"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2022-03-04 01:23:27 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-profiling-run-graph"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2022-06-01 21:01:16 +03:00
|
|
|
"enso-debug-api",
|
2022-03-04 01:23:27 +03:00
|
|
|
"enso-frp",
|
|
|
|
"enso-profiler",
|
2022-04-19 14:30:29 +03:00
|
|
|
"enso-profiler-data",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"enso-profiler-enso-data",
|
2022-03-04 01:23:27 +03:00
|
|
|
"enso-profiler-flame-graph",
|
|
|
|
"enso-web",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-flame-graph",
|
|
|
|
"ensogl-hardcoded-theme",
|
2022-05-03 12:40:27 +03:00
|
|
|
"ensogl-sequence-diagram",
|
2022-03-04 01:23:27 +03:00
|
|
|
"ensogl-text",
|
|
|
|
"ensogl-text-msdf-sys",
|
2022-05-03 12:40:27 +03:00
|
|
|
"ensogl-tooltip",
|
2022-03-04 01:23:27 +03:00
|
|
|
"futures 0.3.21",
|
2022-05-16 15:28:50 +03:00
|
|
|
"qstring",
|
2022-04-19 14:30:29 +03:00
|
|
|
"serde",
|
2022-05-16 15:28:50 +03:00
|
|
|
"url 2.2.2",
|
2022-03-04 01:23:27 +03:00
|
|
|
"wasm-bindgen",
|
2022-04-19 14:30:29 +03:00
|
|
|
"wasm-bindgen-futures",
|
|
|
|
"web-sys",
|
2022-03-04 01:23:27 +03:00
|
|
|
]
|
|
|
|
|
2022-03-21 21:09:56 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-render-profile-flamegraph"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"enso-profiler",
|
|
|
|
"enso-profiler-data",
|
|
|
|
"enso-profiler-flame-graph",
|
|
|
|
"enso-web",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-flame-graph",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-text",
|
|
|
|
"ensogl-text-msdf-sys",
|
2022-05-16 15:28:50 +03:00
|
|
|
"ensogl-tooltip",
|
2022-03-21 21:09:56 +03:00
|
|
|
"futures 0.3.21",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"wasm-bindgen-futures",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-scroll-area"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-scroll-area",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-shape-system"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2022-03-30 05:50:55 +03:00
|
|
|
"enso-profiler",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-core",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-slider"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-selector",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-sprite-system"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2022-03-04 17:13:23 +03:00
|
|
|
"enso-web",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-core",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-sprite-system-benchmark"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-example-text-area"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"ensogl-core",
|
2021-11-12 15:56:23 +03:00
|
|
|
"ensogl-hardcoded-theme",
|
2021-11-10 16:36:08 +03:00
|
|
|
"ensogl-text",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-examples"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-example-animation",
|
|
|
|
"ensogl-example-complex-shape-system",
|
2022-03-30 05:50:55 +03:00
|
|
|
"ensogl-example-custom-shape-system",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-example-dom-symbols",
|
|
|
|
"ensogl-example-drop-manager",
|
|
|
|
"ensogl-example-easing-animator",
|
|
|
|
"ensogl-example-glyph-system",
|
|
|
|
"ensogl-example-list-view",
|
|
|
|
"ensogl-example-mouse-events",
|
2022-03-04 01:23:27 +03:00
|
|
|
"ensogl-example-profiling-run-graph",
|
2022-03-21 21:09:56 +03:00
|
|
|
"ensogl-example-render-profile-flamegraph",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-example-scroll-area",
|
|
|
|
"ensogl-example-shape-system",
|
|
|
|
"ensogl-example-slider",
|
|
|
|
"ensogl-example-sprite-system",
|
|
|
|
"ensogl-example-sprite-system-benchmark",
|
|
|
|
"ensogl-example-text-area",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-file-browser"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
]
|
|
|
|
|
2022-03-04 01:23:27 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-flame-graph"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"enso-profiler",
|
|
|
|
"enso-profiler-flame-graph",
|
|
|
|
"ensogl",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-gui-component",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-text",
|
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-gui-component"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"enso-logger",
|
|
|
|
"ensogl-core",
|
2021-11-10 16:36:08 +03:00
|
|
|
"float_eq",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-12 15:56:23 +03:00
|
|
|
name = "ensogl-hardcoded-theme"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2021-11-12 15:56:23 +03:00
|
|
|
"ensogl-core",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-label"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-shadow",
|
|
|
|
"ensogl-text",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-list-view"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2022-04-30 17:48:52 +03:00
|
|
|
"approx 0.5.1",
|
2021-11-30 14:27:50 +03:00
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-shadow",
|
|
|
|
"ensogl-text",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-scroll-area"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-scrollbar",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-scrollbar"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-gui-component",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-selector",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ensogl-selector"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-shadow",
|
|
|
|
"ensogl-text",
|
|
|
|
"ensogl-toggle-button",
|
|
|
|
"float_eq",
|
|
|
|
]
|
|
|
|
|
2022-05-03 12:40:27 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-sequence-diagram"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"enso-profiler",
|
|
|
|
"enso-profiler-data",
|
|
|
|
"enso-profiler-enso-data",
|
|
|
|
"enso-profiler-flame-graph",
|
|
|
|
"ensogl",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-gui-component",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-text",
|
|
|
|
"ensogl-tooltip",
|
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-shadow"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "ensogl-text"
|
|
|
|
version = "0.1.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-04-12 20:39:08 +03:00
|
|
|
"const_format",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-frp",
|
|
|
|
"enso-prelude",
|
|
|
|
"enso-shapely",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-types",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-text-embedded-fonts",
|
|
|
|
"ensogl-text-msdf-sys",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-10 16:36:08 +03:00
|
|
|
"xi-rope",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "ensogl-text-embedded-fonts"
|
|
|
|
version = "0.1.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-build-utilities",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-prelude",
|
2022-05-26 05:14:11 +03:00
|
|
|
"zip 0.5.13",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "ensogl-text-msdf-sys"
|
|
|
|
version = "0.1.0"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-build-utilities",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-prelude",
|
|
|
|
"ensogl-text-embedded-fonts",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
2021-11-10 16:36:08 +03:00
|
|
|
"js-sys",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-11-30 14:27:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-toggle-button"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
]
|
|
|
|
|
2022-05-03 12:40:27 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ensogl-tooltip"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl-core",
|
|
|
|
"ensogl-hardcoded-theme",
|
|
|
|
"ensogl-label",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "enum_dispatch"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.8"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "0eb359f1476bf611266ac1f5355bc14aeca37b299d0ebccc038ee7058891c9cb"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"once_cell",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "env_logger"
|
|
|
|
version = "0.7.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "44533bbbb3bb3c1fa17d9f2e4e38bbbaf8396ba82193c4cb1b6445d711445d36"
|
|
|
|
dependencies = [
|
|
|
|
"atty",
|
|
|
|
"humantime 1.3.0",
|
|
|
|
"log 0.4.17",
|
|
|
|
"regex",
|
|
|
|
"termcolor",
|
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "event-listener"
|
|
|
|
version = "2.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "77f3309417938f28bf8228fcff79a4a37103981e3e186d2ccd19c74b38f4eb71"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "failure"
|
|
|
|
version = "0.1.8"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "d32e9bd16cc02eae7db7ef620b392808b89f6a5e16bb3497d159c6b92a0f4f86"
|
|
|
|
dependencies = [
|
|
|
|
"backtrace",
|
|
|
|
"failure_derive",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "failure_derive"
|
|
|
|
version = "0.1.8"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "aa4da3c766cd7a0db8242e326e9e4e081edd567072893ed320008189715366a4"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
"synstructure",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "fastrand"
|
|
|
|
version = "1.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c3fcf0cee53519c866c09b5de1f6c56ff9d647101f81c1964fa632e148896cdf"
|
|
|
|
dependencies = [
|
|
|
|
"instant",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "filetime"
|
|
|
|
version = "0.2.16"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c0408e2626025178a6a7f7ffc05a25bc47103229f19c113755de7bf63816290c"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"libc",
|
|
|
|
"redox_syscall 0.2.13",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "flatbuffers"
|
|
|
|
version = "0.5.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "ea0c34f669be9911826facafe996adfda978aeee67285a13556869e2d8b8331f"
|
|
|
|
dependencies = [
|
|
|
|
"smallvec 0.6.14",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "flatc-rust"
|
|
|
|
version = "0.1.3"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "fdce2ac68e3bccc405e0255e9b56d7841c06f6c7d36a8aa8b2966fbb3995bd9a"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "flate2"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.0.23"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "b39522e96686d38f4bc984b9198e3a0613264abaebaff2c5c918bfa6b6da09af"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"crc32fast",
|
|
|
|
"libc",
|
|
|
|
"miniz_oxide",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "flo_stream"
|
|
|
|
version = "0.4.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "b02e0d3667b27514149c1ac9b372d700f3e6df4bbaf6b7c5df12915de2996049"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
|
|
|
"smallvec 1.8.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "float-cmp"
|
|
|
|
version = "0.8.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "e1267f4ac4f343772758f7b1bdcbe767c218bbab93bb432acbf5162bbf85a6c4"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "float_eq"
|
|
|
|
version = "0.5.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "fb23b6902f3cdc0544f9916b4c092f46f4ff984e219d5a0c538b6b3539885af3"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "flume"
|
|
|
|
version = "0.10.12"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "843c03199d0c0ca54bc1ea90ac0d507274c28abcc4f691ae8b4eaa375087c76a"
|
|
|
|
dependencies = [
|
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
|
|
|
"nanorand",
|
|
|
|
"pin-project",
|
|
|
|
"spin 0.9.3",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "fn-error-context"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "236b4e4ae2b8be5f7a5652f6108c4a0f2627c569db4e7923333d31c7dbfed0fb"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "fnv"
|
|
|
|
version = "1.0.7"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "3f9eec918d3f24069decb9af1554cad7c880e2da24a9afd88aca000531ab82c1"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "foreign-types"
|
|
|
|
version = "0.3.2"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "f6f339eb8adc052cd2ca78910fda869aefa38d22d5cb648e6485e4d3fc06f3b1"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"foreign-types-shared",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "foreign-types-shared"
|
|
|
|
version = "0.1.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "00b0228411908ca8685dba7fc2cdd70ec9990a6e753e89b6ac91a84c40fbaf4b"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "form_urlencoded"
|
|
|
|
version = "1.0.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "5fc25a87fa4fd2094bffb06925852034d90a17f0d1e05197d4956d3555752191"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"matches",
|
|
|
|
"percent-encoding 2.1.0",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "fragile"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.2.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "e9d758e60b45e8d749c89c1b389ad8aee550f86aa12e2b9298b546dda7a82ab1"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "fs_extra"
|
|
|
|
version = "1.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2022715d62ab30faffd124d40b76f4134a550a87792276512b18d63272333394"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "fuchsia-cprng"
|
|
|
|
version = "0.1.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "a06f77d526c1a601b7c4cdd98f54b5eaabffc14d5f2f0296febdc7f357c6d3ba"
|
2021-10-30 16:04:07 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "fuchsia-zircon"
|
|
|
|
version = "0.3.3"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "2e9763c69ebaae630ba35f74888db465e49e259ba1bc0eda7d06f4a067615d82"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bitflags",
|
|
|
|
"fuchsia-zircon-sys",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "fuchsia-zircon-sys"
|
|
|
|
version = "0.3.3"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "3dcaa9ae7725d12cdb85b3ad99a434db70b468c09ded17e012d86b5c1010f7a7"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures"
|
|
|
|
version = "0.1.31"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "3a471a38ef8ed83cd6e40aa59c1ffe17db6855c18e3604d9c4ed8c08ebc28678"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "f73fe65f54d1e12b726f517d3e2135ca3125a437b6d998caf1962961f7172d9e"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"futures-executor",
|
|
|
|
"futures-io",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-task",
|
|
|
|
"futures-util",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures-channel"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "c3083ce4b914124575708913bca19bfe887522d6e2e6d0952943f5eac4a74010"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures-core"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "0c09fd04b7e4073ac7156a9539b57a484a8ea920f79c7c675d05d289ab6110d3"
|
2021-10-30 16:04:07 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures-executor"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "9420b90cfa29e327d0429f19be13e7ddb68fa1cccb09d65e5706b8c7a749b8a6"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"futures-core",
|
|
|
|
"futures-task",
|
|
|
|
"futures-util",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures-io"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "fc4045962a5a5e935ee2fdedaa4e08284547402885ab326734432bed5d12966b"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-lite"
|
|
|
|
version = "1.12.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7694489acd39452c77daa48516b894c153f192c3578d5a839b62c58099fcbf48"
|
|
|
|
dependencies = [
|
|
|
|
"fastrand",
|
|
|
|
"futures-core",
|
|
|
|
"futures-io",
|
|
|
|
"memchr",
|
|
|
|
"parking",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"pin-project-lite 0.2.9",
|
2022-02-16 15:58:02 +03:00
|
|
|
"waker-fn",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures-macro"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "33c1e13800337f4d4d7a316bf45a567dbcb6ffe087f16424852d97e97a91f512"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "futures-sink"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "21163e139fa306126e6eedaf49ecdb4588f939600f0b1e770f4205ee4b7fa868"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-task"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "57c66a976bf5909d801bbef33416c41372779507e7a6b3a5e25e4749c58f776a"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "futures-timer"
|
|
|
|
version = "3.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e64b03909df88034c26dc1547e8970b91f98bdb65165d6a4e9110d94263dbb2c"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "futures-util"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.21"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "d8b7abd5d659d9b90c8cba917f6ec750a74e2dc23902ef9cd4cc8c8b22e6036a"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"futures-io",
|
|
|
|
"futures-macro",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-task",
|
|
|
|
"memchr",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"pin-project-lite 0.2.9",
|
2021-11-10 16:36:08 +03:00
|
|
|
"pin-utils",
|
|
|
|
"slab",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "fuzzly"
|
|
|
|
version = "0.1.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-prelude",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "generic-array"
|
|
|
|
version = "0.12.4"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "ffdf9f34f1447443d37393cc6c2b8313aebddcd96906caf34e54c68d8e57d7bd"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"typenum",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "generic-array"
|
|
|
|
version = "0.13.3"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "f797e67af32588215eaaab8327027ee8e71b9dd0b2b26996aedf20c030fce309"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"typenum",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "generic-array"
|
|
|
|
version = "0.14.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fd48d33ec7f05fbfa152300fdad764757cbded343c1aa1cff2fbaf4134851803"
|
|
|
|
dependencies = [
|
|
|
|
"typenum",
|
|
|
|
"version_check 0.9.4",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "getopts"
|
|
|
|
version = "0.2.21"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "14dbbfd5c71d70241ecf9e6f13737f7b5ce823821063188d7e46c41d371eebd5"
|
|
|
|
dependencies = [
|
|
|
|
"unicode-width",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "getrandom"
|
|
|
|
version = "0.1.16"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "8fc3cb4d91f53b50155bdcfd23f6a4c39ae1969c2ae85982b135750cccaf5fce"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"libc",
|
|
|
|
"wasi 0.9.0+wasi-snapshot-preview1",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "getrandom"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.2.6"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "9be70c98951c83b8d2f8f60d7065fa6d5146873094452a1008da8c2f1e4205ad"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"cfg-if 1.0.0",
|
2022-02-16 15:58:02 +03:00
|
|
|
"js-sys",
|
2021-01-25 17:41:20 +03:00
|
|
|
"libc",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"wasi 0.10.0+wasi-snapshot-preview1",
|
2022-02-16 15:58:02 +03:00
|
|
|
"wasm-bindgen",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "gimli"
|
|
|
|
version = "0.26.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "78cc372d058dcf6d5ecd98510e7fbc9e5aec4d21de70f65fea8fecebcd881bd4"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "glob"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9b919933a397b79c37e33b77bb2aa3dc8eb6e165ad809e58ff75bc7db2e34574"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "gloo-timers"
|
|
|
|
version = "0.2.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5fb7d06c1c8cc2a29bee7ec961009a0b2caa0793ee4900c2ffb348734ba1c8f9"
|
|
|
|
dependencies = [
|
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "graphql-introspection-query"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7f2a4732cf5140bd6c082434494f785a19cfb566ab07d1382c3671f5812fed6d"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "graphql-parser"
|
|
|
|
version = "0.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a5613c31f18676f164112732202124f373bb2103ff017b3b85ca954ea6a66ada"
|
|
|
|
dependencies = [
|
|
|
|
"combine",
|
|
|
|
"failure",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "graphql_client"
|
|
|
|
version = "0.10.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a9b58571cfc3cc42c3e8ff44fc6cfbb6c0dea17ed22d20f9d8f1efc4e8209a3f"
|
|
|
|
dependencies = [
|
|
|
|
"graphql_query_derive",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2021-11-12 15:56:23 +03:00
|
|
|
[[package]]
|
2022-05-23 05:16:04 +03:00
|
|
|
name = "graphql_client_codegen"
|
|
|
|
version = "0.10.0"
|
2021-11-12 15:56:23 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "b4bf9cd823359d74ad3d3ecf1afd4a975f4ff2f891cdf9a66744606daf52de8c"
|
|
|
|
dependencies = [
|
|
|
|
"graphql-introspection-query",
|
|
|
|
"graphql-parser",
|
|
|
|
"heck 0.3.3",
|
|
|
|
"lazy_static",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"syn",
|
|
|
|
]
|
2021-11-12 15:56:23 +03:00
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2022-05-23 05:16:04 +03:00
|
|
|
name = "graphql_query_derive"
|
|
|
|
version = "0.10.0"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "e56b093bfda71de1da99758b036f4cc811fd2511c8a76f75680e9ffbd2bb4251"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"graphql_client_codegen",
|
|
|
|
"proc-macro2",
|
|
|
|
"syn",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "h2"
|
|
|
|
version = "0.2.7"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "5e4728fd124914ad25e99e3d15a9361a879f6620f63cb56bbb08f95abb97a535"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 0.5.6",
|
|
|
|
"fnv",
|
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-util",
|
|
|
|
"http",
|
|
|
|
"indexmap",
|
|
|
|
"slab",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
|
|
|
"tokio-util 0.3.1",
|
2021-11-10 16:36:08 +03:00
|
|
|
"tracing",
|
|
|
|
"tracing-futures",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "h2"
|
|
|
|
version = "0.3.13"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "37a82c6d637fc9515a4694bbf1cb2457b79d81ce52b3108bdeea58b07dd34a57"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"fnv",
|
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-util",
|
|
|
|
"http",
|
|
|
|
"indexmap",
|
|
|
|
"slab",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-util 0.7.2",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "half"
|
|
|
|
version = "1.8.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "eabb4a44450da02c90444cf74558da904edde8fb4e9035a9a6a4e15445af0bd7"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hashbrown"
|
|
|
|
version = "0.11.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ab5ef0d4909ef3724cc8cce6ccc8572c5c817592e9285f5464f8e86f8bd3726e"
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "hashbrown"
|
|
|
|
version = "0.12.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "db0d4cf898abf0081f964436dc980e96670a0f36863e4b83aaacdb65c9d7ccc3"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "hdrhistogram"
|
|
|
|
version = "7.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "31672b7011be2c4f7456c4ddbcb40e7e9a4a9fad8efe49a6ebaf5f307d0109c0"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.13.0",
|
|
|
|
"byteorder",
|
|
|
|
"flate2",
|
|
|
|
"nom",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "headers"
|
|
|
|
version = "0.3.7"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4cff78e5788be1e0ab65b04d306b2ed5092c815ec97ec70f4ebd5aee158aa55d"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.13.0",
|
|
|
|
"bitflags",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"headers-core",
|
|
|
|
"http",
|
|
|
|
"httpdate 1.0.2",
|
|
|
|
"mime 0.3.16",
|
|
|
|
"sha-1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "headers-core"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e7f66481bfee273957b1f20485a4ff3362987f85b2c236580d81b4eb7a326429"
|
|
|
|
dependencies = [
|
|
|
|
"http",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "heck"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6d621efb26863f0e9924c6ac577e8275e5e6b77455db64ffa6c65c904e9e132c"
|
|
|
|
dependencies = [
|
|
|
|
"unicode-segmentation",
|
|
|
|
]
|
|
|
|
|
2022-04-19 14:30:29 +03:00
|
|
|
[[package]]
|
|
|
|
name = "heck"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2540771e65fc8cb83cd6e8a237f70c319bd5c29f78ed1084ba5d50eeac86f7f9"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "hermit-abi"
|
|
|
|
version = "0.1.19"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "62b467343b94ba476dcb2500d242dadbb39557df889310ac77c5d99100aaac33"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"libc",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "hex"
|
|
|
|
version = "0.4.3"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "7f24254aa9a54b5c858eaee2f5bccdb46aaf0e486a595ed5fd8f86ba55232a70"
|
2021-10-30 16:04:07 +03:00
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "hmac"
|
|
|
|
version = "0.12.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6c49c37c09c17a53d937dfbb742eb3a961d65a994e6bcdcf37e7399d0cc8ab5e"
|
|
|
|
dependencies = [
|
|
|
|
"digest 0.10.3",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "http"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.2.7"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "ff8670570af52249509a86f5e3e18a08c60b177071826898fde8997cf5f6bfbb"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 1.1.0",
|
|
|
|
"fnv",
|
2022-05-23 05:16:04 +03:00
|
|
|
"itoa 1.0.2",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "http-body"
|
|
|
|
version = "0.3.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "13d5ff830006f7646652e057693569bfe0d51760c0085a071769d142a205111b"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 0.5.6",
|
|
|
|
"http",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "http-body"
|
|
|
|
version = "0.4.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d5f38f16d184e36f2408a55281cd658ecbd3ca05cce6d6510a176eca393e26d1"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"http",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "http-range-header"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0bfe8eed0a9285ef776bb792479ea3834e8b94e13d615c2f66d03dd50a435a29"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "http-serde"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6d98b3d9662de70952b14c4840ee0f37e23973542a363e2275f4b9d024ff6cca"
|
|
|
|
dependencies = [
|
|
|
|
"http",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "http-types"
|
|
|
|
version = "2.12.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6e9b187a72d63adbfba487f48095306ac823049cb504ee195541e91c7775f5ad"
|
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"async-channel",
|
|
|
|
"base64 0.13.0",
|
|
|
|
"futures-lite",
|
|
|
|
"http",
|
|
|
|
"infer",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
"rand 0.7.3",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"serde_qs",
|
|
|
|
"serde_urlencoded",
|
|
|
|
"url 2.2.2",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "httparse"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.7.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "496ce29bb5a52785b44e0f7ca2847ae0bb839c9bd28f69acac9b99d461c0c04c"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "httpdate"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "494b4d60369511e7dea41cf646832512a94e542f68bb9c49e54518e0f468eb47"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "httpdate"
|
|
|
|
version = "1.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c4a1e36c821dbe04574f602848a19f742f4fb3c98d40449f11bcad18d6b17421"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "humantime"
|
|
|
|
version = "1.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "df004cfca50ef23c36850aaaa59ad52cc70d0e90243c3c7737a4dd32dc7a3c4f"
|
|
|
|
dependencies = [
|
|
|
|
"quick-error",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "humantime"
|
|
|
|
version = "2.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9a3a5bfb195931eeb336b2a7b4d761daec841b97f947d34394601737a7bba5e4"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "hyper"
|
|
|
|
version = "0.10.16"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0a0652d9a2609a968c14be1a9ea00bf4b1d64e2e1f53a1b51b6fff3a6e829273"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.9.3",
|
|
|
|
"httparse",
|
2022-05-23 05:16:04 +03:00
|
|
|
"language-tags 0.2.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"log 0.3.9",
|
|
|
|
"mime 0.2.6",
|
|
|
|
"num_cpus",
|
2022-05-23 05:16:04 +03:00
|
|
|
"time 0.1.44",
|
2021-11-10 16:36:08 +03:00
|
|
|
"traitobject",
|
|
|
|
"typeable",
|
|
|
|
"unicase 1.4.2",
|
|
|
|
"url 1.7.2",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hyper"
|
|
|
|
version = "0.13.10"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8a6f157065790a3ed2f88679250419b5cdd96e714a0d65f7797fd337186e96bb"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 0.5.6",
|
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
2022-05-23 05:16:04 +03:00
|
|
|
"h2 0.2.7",
|
2021-11-10 16:36:08 +03:00
|
|
|
"http",
|
2022-05-23 05:16:04 +03:00
|
|
|
"http-body 0.3.1",
|
2021-11-10 16:36:08 +03:00
|
|
|
"httparse",
|
2022-05-23 05:16:04 +03:00
|
|
|
"httpdate 0.3.2",
|
2022-02-16 15:58:02 +03:00
|
|
|
"itoa 0.4.8",
|
2021-11-10 16:36:08 +03:00
|
|
|
"pin-project",
|
2022-02-16 15:58:02 +03:00
|
|
|
"socket2 0.3.19",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
|
|
|
"tower-service",
|
|
|
|
"tracing",
|
|
|
|
"want",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hyper"
|
|
|
|
version = "0.14.18"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b26ae0a80afebe130861d90abf98e3814a4f28a4c6ffeb5ab8ebb2be311e0ef2"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"h2 0.3.13",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"httparse",
|
|
|
|
"httpdate 1.0.2",
|
|
|
|
"itoa 1.0.2",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
"socket2 0.4.4",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"tower-service",
|
|
|
|
"tracing",
|
|
|
|
"want",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "hyper-rustls"
|
|
|
|
version = "0.22.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5f9f7a97316d44c0af9b0301e65010573a853a9fc97046d7331d7f6bc0fd5a64"
|
|
|
|
dependencies = [
|
|
|
|
"ct-logs",
|
|
|
|
"futures-util",
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"log 0.4.17",
|
|
|
|
"rustls 0.19.1",
|
|
|
|
"rustls-native-certs",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-rustls 0.22.0",
|
|
|
|
"webpki 0.21.4",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hyper-rustls"
|
|
|
|
version = "0.23.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d87c48c02e0dc5e3b849a2041db3029fd066650f8f717c07bf8ed78ccb895cac"
|
|
|
|
dependencies = [
|
|
|
|
"http",
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"rustls 0.20.6",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-rustls 0.23.4",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hyper-timeout"
|
|
|
|
version = "0.4.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bbb958482e8c7be4bc3cf272a766a2b0bf1a6755e7a6ae777f017a31d11b13b1"
|
|
|
|
dependencies = [
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"pin-project-lite 0.2.9",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-io-timeout",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "hyper-tls"
|
|
|
|
version = "0.4.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d979acc56dcb5b8dddba3917601745e877576475aa046df3226eabdecef78eed"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 0.5.6",
|
|
|
|
"hyper 0.13.10",
|
|
|
|
"native-tls",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
2021-11-10 16:36:08 +03:00
|
|
|
"tokio-tls 0.3.1",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "hyperx"
|
|
|
|
version = "1.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5617e92fc2f2501c3e2bc6ce547cad841adba2bae5b921c7e52510beca6d084c"
|
|
|
|
dependencies = [
|
2022-06-14 09:38:56 +03:00
|
|
|
"base64 0.11.0",
|
2022-05-23 05:16:04 +03:00
|
|
|
"bytes 1.1.0",
|
|
|
|
"http",
|
2022-06-14 09:38:56 +03:00
|
|
|
"httpdate 1.0.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"language-tags 0.3.2",
|
|
|
|
"mime 0.3.16",
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"unicase 2.6.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ide-ci"
|
|
|
|
version = "0.1.0"
|
2022-06-14 09:38:56 +03:00
|
|
|
source = "git+https://github.com/enso-org/ci-build?branch=develop#75db499c249c91b55b5c801632ac33291619076c"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"async-compression",
|
|
|
|
"async-trait",
|
|
|
|
"bincode",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"byte-unit",
|
2022-05-23 05:16:04 +03:00
|
|
|
"bytes 1.1.0",
|
|
|
|
"cached",
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"chrono",
|
|
|
|
"clap 3.1.18",
|
|
|
|
"convert_case 0.5.0",
|
|
|
|
"data-encoding",
|
|
|
|
"derivative",
|
|
|
|
"derive_more",
|
|
|
|
"dirs",
|
|
|
|
"filetime",
|
|
|
|
"flate2",
|
|
|
|
"flume",
|
|
|
|
"fn-error-context",
|
|
|
|
"fs_extra",
|
|
|
|
"futures 0.3.21",
|
|
|
|
"futures-util",
|
|
|
|
"glob",
|
|
|
|
"graphql_client",
|
|
|
|
"headers",
|
|
|
|
"heck 0.4.0",
|
|
|
|
"http-serde",
|
|
|
|
"ifmt",
|
|
|
|
"indexmap",
|
|
|
|
"indicatif",
|
|
|
|
"itertools 0.10.3",
|
|
|
|
"lazy_static",
|
|
|
|
"log 0.4.17",
|
|
|
|
"mime 0.3.16",
|
|
|
|
"new_mime_guess",
|
2022-05-26 05:14:11 +03:00
|
|
|
"nix",
|
2022-05-23 05:16:04 +03:00
|
|
|
"octocrab",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"paste 1.0.7",
|
2022-05-23 05:16:04 +03:00
|
|
|
"path-absolutize",
|
|
|
|
"path-slash",
|
|
|
|
"pathdiff",
|
|
|
|
"pin-project",
|
|
|
|
"platforms",
|
|
|
|
"port_check",
|
|
|
|
"pretty_env_logger",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"rand 0.8.5",
|
|
|
|
"regex",
|
|
|
|
"reqwest 0.11.10",
|
|
|
|
"scopeguard",
|
|
|
|
"semver 1.0.9",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"serde_yaml",
|
|
|
|
"sha2",
|
|
|
|
"shrinkwraprs 0.3.0",
|
2022-05-26 05:14:11 +03:00
|
|
|
"snafu",
|
|
|
|
"strum",
|
2022-05-23 05:16:04 +03:00
|
|
|
"symlink",
|
|
|
|
"syn",
|
|
|
|
"sysinfo",
|
|
|
|
"tar",
|
|
|
|
"tempfile",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-26 05:14:11 +03:00
|
|
|
"tokio-util 0.7.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tracing",
|
|
|
|
"tracing-subscriber",
|
|
|
|
"unicase 2.6.0",
|
|
|
|
"url 2.2.2",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 1.1.0",
|
2022-05-23 05:16:04 +03:00
|
|
|
"walkdir",
|
|
|
|
"which",
|
|
|
|
"whoami",
|
|
|
|
"wiremock",
|
2022-05-26 05:14:11 +03:00
|
|
|
"zip 0.6.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ide-view"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ast",
|
|
|
|
"engine-protocol",
|
|
|
|
"enso-config",
|
|
|
|
"enso-frp",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
|
|
|
"enso-shapely",
|
|
|
|
"ensogl",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-component",
|
2021-11-12 15:56:23 +03:00
|
|
|
"ensogl-hardcoded-theme",
|
2021-11-10 16:36:08 +03:00
|
|
|
"ensogl-text",
|
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"ide-view-graph-editor",
|
|
|
|
"js-sys",
|
2021-12-15 13:40:14 +03:00
|
|
|
"multi-map",
|
2021-11-10 16:36:08 +03:00
|
|
|
"nalgebra 0.26.2",
|
2022-02-16 15:58:02 +03:00
|
|
|
"ordered-float 2.10.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"parser",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"span-tree",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
2021-11-30 18:23:46 +03:00
|
|
|
"welcome-screen",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-04-14 13:37:40 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ide-view-component-group"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
2022-05-24 10:48:19 +03:00
|
|
|
"ensogl",
|
2022-04-14 13:37:40 +03:00
|
|
|
"ensogl-gui-component",
|
|
|
|
"ensogl-hardcoded-theme",
|
2022-05-12 12:30:00 +03:00
|
|
|
"ensogl-label",
|
2022-04-14 13:37:40 +03:00
|
|
|
"ensogl-list-view",
|
2022-05-17 16:52:08 +03:00
|
|
|
"ensogl-shadow",
|
2022-04-14 13:37:40 +03:00
|
|
|
"ensogl-text",
|
2022-05-24 10:48:19 +03:00
|
|
|
"failure",
|
2022-04-14 13:37:40 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ide-view-graph-editor"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"analytics",
|
|
|
|
"ast",
|
2022-01-11 15:31:43 +03:00
|
|
|
"base64 0.13.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"bimap",
|
|
|
|
"engine-protocol",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-config",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-frp",
|
|
|
|
"enso-logger",
|
|
|
|
"enso-prelude",
|
|
|
|
"enso-shapely",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-10 16:36:08 +03:00
|
|
|
"ensogl",
|
2021-11-30 14:27:50 +03:00
|
|
|
"ensogl-component",
|
2021-11-12 15:56:23 +03:00
|
|
|
"ensogl-drop-manager",
|
|
|
|
"ensogl-hardcoded-theme",
|
2021-11-10 16:36:08 +03:00
|
|
|
"ensogl-text-msdf-sys",
|
|
|
|
"failure",
|
|
|
|
"js-sys",
|
|
|
|
"nalgebra 0.26.2",
|
|
|
|
"ordered-float 1.1.1",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2022-01-11 15:31:43 +03:00
|
|
|
"sourcemap",
|
2021-11-10 16:36:08 +03:00
|
|
|
"span-tree",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ident_case"
|
|
|
|
version = "1.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b9e0384b61958566e926dc50660321d12159025e767c18e043daf26b70104c39"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "idna"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "38f09e0f0b1fb55fdee1f17470ad800da77af5186a1a76c026b679358b7e844e"
|
|
|
|
dependencies = [
|
|
|
|
"matches",
|
|
|
|
"unicode-bidi",
|
|
|
|
"unicode-normalization",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "idna"
|
|
|
|
version = "0.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "418a0a6fab821475f634efe3ccc45c013f742efe03d853e8d3355d5cb850ecf8"
|
|
|
|
dependencies = [
|
|
|
|
"matches",
|
|
|
|
"unicode-bidi",
|
|
|
|
"unicode-normalization",
|
|
|
|
]
|
|
|
|
|
2022-01-11 15:31:43 +03:00
|
|
|
[[package]]
|
|
|
|
name = "if_chain"
|
|
|
|
version = "1.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cb56e1aa765b4b4f3aadfab769793b7087bb03a4ea4920644a6d238e2df5b9ed"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ifmt"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7dd0f8e1404f15475d8a2ca84c2942aa00ac17804ce555294a96f6b5cdf80750"
|
|
|
|
dependencies = [
|
|
|
|
"ifmt-impl",
|
|
|
|
"proc-macro-hack",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ifmt-impl"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e50385662f423431a619ab28ba2beeab3063b581a0d1a943765e23911c502904"
|
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"proc-macro-hack",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"regex",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "indexmap"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.8.1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "0f647032dfaa1f8b6dc29bd3edb7bbef4861b8b8007ebb118d6db284fd59f6ee"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2022-05-26 05:14:11 +03:00
|
|
|
"hashbrown 0.11.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "indicatif"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.17.0-rc.11"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "4017d0ce94b8e91e29d2c78ed891e57e5ec3dc4371820a9d96abab4af09eb8ad"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"console",
|
|
|
|
"number_prefix",
|
|
|
|
"unicode-width",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "infer"
|
|
|
|
version = "0.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "64e9829a50b42bb782c1df523f78d332fe371b10c661e78b7a3c34b0198e9fac"
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "instant"
|
|
|
|
version = "0.1.12"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7a5bbe824c507c5da5956355e86a746d82e0e1464f65d862cc5e71da70e94b2c"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "iovec"
|
|
|
|
version = "0.1.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b2b3ea6ff95e175473f8ffe6a7eb7c00d054240321b84c57051175fe3c1e075e"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ipnet"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "2.5.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "879d54834c8c76457ef4293a689b2a8c59b076067ad77b15efafbb05f92a592b"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "itertools"
|
|
|
|
version = "0.8.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f56a2d0bc861f9165be4eb3442afd3c236d8a98afd426f65d92324ae1091a484"
|
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "itertools"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "284f18f85651fe11e8a991b2adb42cb078325c996ed026d994719efcfca1d54b"
|
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "itertools"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.10.3"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "a9a9d19fa1e79b6215ff29b9d6880b706147f16e9b1dbb1e4e5947b5b02bc5e3"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "itoa"
|
|
|
|
version = "0.4.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b71991ff56294aa922b450139ee08b3bfc70982c6b2c7562771375cf73542dd4"
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "itoa"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "1.0.2"
|
2022-02-16 15:58:02 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "112c678d4050afce233f4f2852bb2eb519230b3cf12f33585275537d7e41578d"
|
2022-02-16 15:58:02 +03:00
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "jobserver"
|
|
|
|
version = "0.1.24"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "af25a77299a7f711a01975c35a6a424eb6862092cc2d6c72c4ed6cbc56dfc1fa"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "js-sys"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.55"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "7cc9ffccd38c451a86bf13657df244e9c3f37493cce8e5e21e940963777acc84"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "json-rpc"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-prelude",
|
2022-04-19 14:30:29 +03:00
|
|
|
"enso-profiler",
|
2022-04-21 12:38:26 +03:00
|
|
|
"enso-profiler-data",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-shapely",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-web",
|
2021-11-10 16:36:08 +03:00
|
|
|
"failure",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"shrinkwraprs 0.3.0",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "jsonwebtoken"
|
2022-06-01 14:44:40 +03:00
|
|
|
version = "8.1.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-06-01 14:44:40 +03:00
|
|
|
checksum = "cc9051c17f81bae79440afa041b3a278e1de71bfb96d32454b477fd4703ccb6f"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
2022-06-01 14:44:40 +03:00
|
|
|
"base64 0.13.0",
|
2022-05-23 05:16:04 +03:00
|
|
|
"pem",
|
|
|
|
"ring",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"simple_asn1",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "keccak"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.1.2"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "f9b7d56ba4a8344d6be9729995e6b06f928af29998cdf79fe390cbf6b1fee838"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "kernel32-sys"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7507624b29483431c0ba2d82aece8ca6cdba9382bff4ddd0f7490560c056098d"
|
|
|
|
dependencies = [
|
|
|
|
"winapi 0.2.8",
|
|
|
|
"winapi-build",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "keyboard-types"
|
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a989afac88279b0482f402d234b5fbd405bf1ad051308595b58de4e6de22346b"
|
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
"serde",
|
|
|
|
"unicode-segmentation",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "kv-log-macro"
|
|
|
|
version = "1.0.7"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0de8b303297635ad57c9f5059fd9cee7a47f8e8daa09df0fcd07dd39fb22977f"
|
|
|
|
dependencies = [
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "language-tags"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a91d884b6667cd606bb5a69aa0c99ba811a115fc68915e7056ec08a46e93199a"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "language-tags"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d4345964bb142484797b161f473a503a434de77149dd8c7427788c6e13379388"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "launcher-shims"
|
|
|
|
version = "0.1.0"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "lazy_static"
|
|
|
|
version = "1.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e2abad23fbc42b3700f2f279844dc832adb2b2eb069b2df918f455c4e18cc646"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libc"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "0.2.126"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "349d5a591cd28b49e1d1037471617a32ddcda5731b99419008085f72d5a53836"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libm"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.2"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "33a33a362ce288760ec6a508b94caaec573ae7d3bbbd91b87aa0bad4456839db"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "linked-hash-map"
|
|
|
|
version = "0.5.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7fb9b38af92608140b86b693604b9ffcc5824240a484d1ecd4795bacb2fe88f3"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "lock_api"
|
|
|
|
version = "0.3.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "c4da24a77a3d8a6d4862d95f72e6fdb9c09a643ecdb402d754004a557f2bec75"
|
|
|
|
dependencies = [
|
|
|
|
"scopeguard",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "lock_api"
|
|
|
|
version = "0.4.7"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "327fa5b6a6940e4699ec49a9beae1ea4845c6bab9314e4f84ac68742139d8c53"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"scopeguard",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "log"
|
|
|
|
version = "0.3.9"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e19e8d5c34a3e0e2223db8e060f9e8264aeeb5c5fc64a4ee9965c062211c024b"
|
|
|
|
dependencies = [
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "log"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.4.17"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "abb12e687cfb44aa40f41fc3978ef76448f9b6038cad6aef4259d3c095a2382e"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"value-bag",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "matchers"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8263075bb86c5a1b1427b5ae862e8889656f126e9f77c484496e8b47cf5c5558"
|
|
|
|
dependencies = [
|
|
|
|
"regex-automata",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "matches"
|
|
|
|
version = "0.1.9"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a3e378b66a060d48947b590737b30a1be76706c8dd7b8ba0f2fe3989c68a853f"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "matchit"
|
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "73cbba799671b762df5a175adf59ce145165747bb891505c43d09aefbbf38beb"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "matrixmultiply"
|
|
|
|
version = "0.2.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "916806ba0031cd542105d916a97c8572e1fa6dd79c9c51e7eb43a09ec2dd84c1"
|
|
|
|
dependencies = [
|
|
|
|
"rawpointer",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "matrixmultiply"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.2"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "add85d4dd35074e6fedc608f8c8f513a3548619a9024b751949ef0e8e45a4d84"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"rawpointer",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "maybe-uninit"
|
|
|
|
version = "2.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "60302e4db3a61da70c0cb7991976248362f30319e88850c487b9b95bbf059e00"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "md5"
|
|
|
|
version = "0.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "490cc448043f947bae3cbee9c203358d62dbee0db12107a74be5c30ccfd09771"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "memchr"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "2.5.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "2dffe52ecf27772e601905b7522cb4ef790d2cc203488bbd0e2fe85fcb74566d"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "memoffset"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.6.5"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "5aa361d4faea93603064a027415f07bd8e1d5c88c9fbf68bf56a285428fd79ce"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mime"
|
|
|
|
version = "0.2.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ba626b8a6de5da682e1caa06bdb42a335aee5a84db8e5046a3e8ab17ba0a3ae0"
|
|
|
|
dependencies = [
|
|
|
|
"log 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mime"
|
|
|
|
version = "0.3.16"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2a60c7ce501c71e03a9c9c0d35b861413ae925bd979cc7a4e30d060069aaac8d"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mime_guess"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "2.0.4"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "4192263c238a5f0d0c6bfd21f336a313a4ce1c450542449ca191bb657b4642ef"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"mime 0.3.16",
|
|
|
|
"unicase 2.6.0",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "minimal-lexical"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "68354c5c6bd36d73ff3feceb05efa59b6acb7626617f4962be322a825e61f79a"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "miniz_oxide"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.5.1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "d2b29bd4bc3f33391105ebee3589c19197c4271e3e5a9ec9bfe8127eeff8f082"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"adler",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mio"
|
|
|
|
version = "0.6.23"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4afd66f5b91bf2a3bc13fad0e21caedac168ca4c707504e75585648ae80e4cc4"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 0.1.10",
|
|
|
|
"fuchsia-zircon",
|
|
|
|
"fuchsia-zircon-sys",
|
|
|
|
"iovec",
|
|
|
|
"kernel32-sys",
|
|
|
|
"libc",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
"miow",
|
|
|
|
"net2",
|
|
|
|
"slab",
|
|
|
|
"winapi 0.2.8",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "mio"
|
|
|
|
version = "0.8.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "713d550d9b44d89174e066b7a6217ae06234c10cb47819a88290d2b353c31799"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"log 0.4.17",
|
|
|
|
"wasi 0.11.0+wasi-snapshot-preview1",
|
|
|
|
"windows-sys",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "miow"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ebd808424166322d4a38da87083bfddd3ac4c131334ed55856112eb06d46944d"
|
|
|
|
dependencies = [
|
|
|
|
"kernel32-sys",
|
|
|
|
"net2",
|
|
|
|
"winapi 0.2.8",
|
|
|
|
"ws2_32-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mockall"
|
|
|
|
version = "0.7.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "01458f8a19b10cb28195290942e3149161c75acf67ebc8fbf714ab67a2b943bc"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 0.1.10",
|
|
|
|
"downcast",
|
|
|
|
"fragile",
|
|
|
|
"lazy_static",
|
|
|
|
"mockall_derive",
|
|
|
|
"predicates",
|
|
|
|
"predicates-tree",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mockall_derive"
|
|
|
|
version = "0.7.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a673cb441f78cd9af4f5919c28576a3cc325fb6b54e42f7047dacce3c718c17b"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 0.1.10",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-12-15 13:40:14 +03:00
|
|
|
[[package]]
|
|
|
|
name = "multi-map"
|
|
|
|
version = "1.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bba551d6d795f74a01767577ea8339560bf0a65354e0417b7e915ed608443d46"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "nalgebra"
|
|
|
|
version = "0.21.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d6b6147c3d50b4f3cdabfe2ecc94a0191fd3d6ad58aefd9664cf396285883486"
|
|
|
|
dependencies = [
|
|
|
|
"approx 0.3.2",
|
|
|
|
"generic-array 0.13.3",
|
|
|
|
"matrixmultiply 0.2.4",
|
|
|
|
"num-complex 0.2.4",
|
|
|
|
"num-rational 0.2.4",
|
|
|
|
"num-traits",
|
|
|
|
"rand 0.7.3",
|
|
|
|
"rand_distr",
|
|
|
|
"serde",
|
|
|
|
"serde_derive",
|
|
|
|
"simba 0.1.5",
|
|
|
|
"typenum",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nalgebra"
|
|
|
|
version = "0.26.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "476d1d59fe02fe54c86356e91650cd892f392782a1cb9fc524ec84f7aa9e1d06"
|
|
|
|
dependencies = [
|
|
|
|
"approx 0.4.0",
|
2022-02-16 15:58:02 +03:00
|
|
|
"matrixmultiply 0.3.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-complex 0.3.1",
|
|
|
|
"num-rational 0.3.2",
|
|
|
|
"num-traits",
|
|
|
|
"serde",
|
|
|
|
"simba 0.4.0",
|
|
|
|
"typenum",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "nanorand"
|
|
|
|
version = "0.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6a51313c5820b0b02bd422f4b44776fbf47961755c74ce64afc73bfad10226c3"
|
|
|
|
dependencies = [
|
|
|
|
"getrandom 0.2.6",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "native-tls"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.2.10"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "fd7e2f3618557f980e0b17e8856252eee3c97fa12c54dff0ca290fb6266ca4a9"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"libc",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
"openssl",
|
|
|
|
"openssl-probe",
|
|
|
|
"openssl-sys",
|
|
|
|
"schannel",
|
|
|
|
"security-framework",
|
|
|
|
"security-framework-sys",
|
|
|
|
"tempfile",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "net2"
|
|
|
|
version = "0.2.37"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "391630d12b68002ae1e25e8f974306474966550ad82dac6886fb8910c19568ae"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 0.1.10",
|
|
|
|
"libc",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "new_mime_guess"
|
|
|
|
version = "4.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c2d684d1b59e0dc07b37e2203ef576987473288f530082512aff850585c61b1f"
|
|
|
|
dependencies = [
|
|
|
|
"mime 0.3.16",
|
|
|
|
"unicase 2.6.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nix"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.24.1"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "8f17df307904acd05aa8e32e97bb20f2a0df1728bbc2d771ae8f9a90463441e9"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"libc",
|
|
|
|
"memoffset",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nom"
|
|
|
|
version = "7.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a8903e5a29a317527874d0402f867152a3d21c908bb0b933e416c65e301d4c36"
|
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
"minimal-lexical",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "normalize-line-endings"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "61807f77802ff30975e01f4f071c8ba10c022052f98b3294119f3e615d13e5be"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ntapi"
|
|
|
|
version = "0.3.7"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c28774a7fd2fbb4f0babd8237ce554b73af68021b5f695a3cebd6c59bac0980f"
|
|
|
|
dependencies = [
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "num"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "43db66d1170d347f9a065114077f7dccb00c1b9478c89384490a3425279a4606"
|
|
|
|
dependencies = [
|
2022-06-01 14:44:40 +03:00
|
|
|
"num-bigint",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"num-complex 0.4.1",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-integer",
|
|
|
|
"num-iter",
|
|
|
|
"num-rational 0.4.0",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-bigint"
|
|
|
|
version = "0.4.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f93ab6289c7b344a8a9f60f88d80aa20032336fe78da341afc91c8a2341fc75f"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-complex"
|
|
|
|
version = "0.2.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b6b19411a9719e753aff12e5187b74d60d3dc449ec3f4dc21e3989c3f554bc95"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-traits",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-complex"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "747d632c0c558b87dbabbe6a82f3b4ae03720d0646ac5b7b4dae89394be5f2c5"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-complex"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.4.1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "97fbc387afefefd5e9e39493299f3069e14a140dd34dc19b4c1c1a8fddb6a790"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-integer"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.1.45"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "225d3389fb3509a24c93f5c29eb6bde2586b98d9f016636dff58d7c6f7569cd9"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-iter"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.1.43"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "7d03e6c028c5dc5cac6e2dec0efda81fc887605bb3d884578bb6d6bf7514e252"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-rational"
|
|
|
|
version = "0.2.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5c000134b5dbf44adc5cb772486d335293351644b801551abe8f75c84cfa4aef"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-rational"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "12ac428b1cb17fce6f731001d307d351ec70a6d202fc2e60f7d4c5e42d8f4f07"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-rational"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d41702bd167c2df5520b384281bc111a4b5efcf7fbc4c9c222c815b07e0a6a6a"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2022-06-01 14:44:40 +03:00
|
|
|
"num-bigint",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-traits"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.2.15"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "578ede34cf02f8924ab9447f50c28075b4d3e5b269972345e7e0372b38c6cdcd"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"libm",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num_cpus"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.13.1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "19e64526ebdee182341572e50e9ad03965aa510cd94427a4549448f285e957a1"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"hermit-abi",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num_enum"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.5.7"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "cf5395665662ef45796a4ff5486c5d41d29e0c09640af4c5f17fd94ee2c119c9"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"num_enum_derive",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num_enum_derive"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.5.7"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "3b0498641e53dd6ac1a4f22547548caa6864cc4933784319cd1775271c5a46ce"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro-crate",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "num_threads"
|
|
|
|
version = "0.1.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2819ce041d2ee131036f4fc9d6ae7ae125a3a40e97ba64d04fe799ad9dabbb44"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "number_prefix"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "830b246a0e5f20af87141b25c173cd1b609bd7779a4617d6ec582abaf90870f3"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "object"
|
|
|
|
version = "0.24.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1a5b3dd1c072ee7963717671d1ca129f1048fda25edea6b752bfc71ac8854170"
|
|
|
|
dependencies = [
|
|
|
|
"flate2",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "object"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "0.28.4"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "e42c982f2d955fac81dd7e1d0e1426a7d702acd9c98d19ab01083a6a0328c424"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "octocrab"
|
2022-06-01 14:44:40 +03:00
|
|
|
version = "0.16.0"
|
|
|
|
source = "git+https://github.com/enso-org/octocrab#2a104c9673f45d48ae0438d0b05bcd905eb1334b"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"arc-swap",
|
|
|
|
"async-trait",
|
|
|
|
"base64 0.13.0",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"chrono",
|
|
|
|
"hyperx",
|
|
|
|
"jsonwebtoken",
|
|
|
|
"once_cell",
|
|
|
|
"reqwest 0.11.10",
|
2022-06-01 14:44:40 +03:00
|
|
|
"secrecy",
|
2022-05-23 05:16:04 +03:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"serde_path_to_error",
|
2022-05-26 05:14:11 +03:00
|
|
|
"snafu",
|
2022-05-23 05:16:04 +03:00
|
|
|
"url 2.2.2",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "once_cell"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "1.12.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "7709cef83f0c1f58f666e746a08b21e0085f7440fa6a29cc194d68aac97a4225"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "oorandom"
|
|
|
|
version = "11.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0ab1bc2a289d34bd04a330323ac98a1b4bc82c9d9fcb1e66b63caa84da26b575"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "opaque-debug"
|
|
|
|
version = "0.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2839e79665f131bdb5782e51f2c6c9599c133c6098982a54c794358bf432529c"
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "opaque-debug"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "624a8340c38c1b80fd549087862da4ba43e08858af025b236e509b6649fc13d5"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "openssl"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.10.40"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "fb81a6430ac911acb25fe5ac8f1d2af1b4ea8a4fdfda0f1ee4292af2e2d8eb0e"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"foreign-types",
|
|
|
|
"libc",
|
|
|
|
"once_cell",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"openssl-macros",
|
2021-11-10 16:36:08 +03:00
|
|
|
"openssl-sys",
|
|
|
|
]
|
|
|
|
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
[[package]]
|
|
|
|
name = "openssl-macros"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b501e44f11665960c7e7fcf062c7d96a14ade4aa98116c004b2e37b5be7d736c"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "openssl-probe"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.1.5"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "ff011a302c396a5197692431fc1948019154afc178baf7d8e37367442a4601cf"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "openssl-sys"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.9.73"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "9d5fd19fb3e0a8191c1e34935718976a3e70c112ab9a24af6d7cadccd9d90bc0"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"cc",
|
|
|
|
"libc",
|
|
|
|
"pkg-config",
|
|
|
|
"vcpkg",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ordered-float"
|
|
|
|
version = "1.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3305af35278dd29f46fcdd139e0b1fbfae2153f0e5928b39b035542dd31e37b7"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ordered-float"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "2.10.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "7940cf2ca942593318d07fcf2596cdca60a85c9e7fab408a5e21a4f9dcd40d87"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "os_str_bytes"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "6.1.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "21326818e99cfe6ce1e524c2a805c189a99b5ae555a35d19f9a284b427d86afa"
|
2022-05-23 05:16:04 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ouroboros"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.15.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "9f31a3b678685b150cba82b702dcdc5e155893f63610cf388d30cd988d4ca2bf"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"aliasable",
|
|
|
|
"ouroboros_macro",
|
|
|
|
"stable_deref_trait",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ouroboros_macro"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.15.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "084fd65d5dd8b3772edccb5ffd1e4b7eba43897ecd0f9401e330e8c542959408"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
|
|
|
"proc-macro-error",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "parking"
|
|
|
|
version = "2.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "427c3892f9e783d91cc128285287e70a59e206ca452770ece88a76f7a3eddd72"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "parking_lot"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f842b1982eb6c2fe34036a4fbfb06dd185a3f5c8edfaacdf7d1ea10b07de6252"
|
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"lock_api 0.3.4",
|
|
|
|
"parking_lot_core 0.6.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"rustc_version 0.2.3",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "parking_lot"
|
|
|
|
version = "0.12.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "87f5ec2493a61ac0506c0f4199f99070cbe83857b0337006a30f3e6719b8ef58"
|
|
|
|
dependencies = [
|
|
|
|
"lock_api 0.4.7",
|
|
|
|
"parking_lot_core 0.9.3",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "parking_lot_core"
|
|
|
|
version = "0.6.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b876b1b9e7ac6e1a74a6da34d25c42e17e8862aa409cbbbdcfc8d86c6f3bc62b"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 0.1.10",
|
|
|
|
"cloudabi",
|
|
|
|
"libc",
|
|
|
|
"redox_syscall 0.1.57",
|
|
|
|
"rustc_version 0.2.3",
|
|
|
|
"smallvec 0.6.14",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "parking_lot_core"
|
|
|
|
version = "0.9.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "09a279cbf25cb0757810394fbc1e359949b59e348145c643a939a525692e6929"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"libc",
|
|
|
|
"redox_syscall 0.2.13",
|
|
|
|
"smallvec 1.8.0",
|
|
|
|
"windows-sys",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "parser"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ast",
|
|
|
|
"bytes 0.5.6",
|
|
|
|
"console_error_panic_hook",
|
2021-11-12 15:56:23 +03:00
|
|
|
"enso-build-utilities",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-prelude",
|
2022-03-21 21:09:56 +03:00
|
|
|
"enso-profiler",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-10 16:36:08 +03:00
|
|
|
"failure",
|
2022-02-16 15:58:02 +03:00
|
|
|
"futures 0.3.21",
|
2021-11-10 16:36:08 +03:00
|
|
|
"js-sys",
|
|
|
|
"matches",
|
2022-05-23 05:16:04 +03:00
|
|
|
"reqwest 0.10.10",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"shrinkwraprs 0.2.3",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
2022-05-26 05:14:11 +03:00
|
|
|
"uuid 0.8.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-10 16:36:08 +03:00
|
|
|
"websocket",
|
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "password-hash"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1d791538a6dcc1e7cb7fe6f6b58aca40e7f79403c45b2bc274008b5e647af1d8"
|
|
|
|
dependencies = [
|
|
|
|
"base64ct",
|
|
|
|
"rand_core 0.6.3",
|
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "paste"
|
|
|
|
version = "0.1.18"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "45ca20c77d80be666aef2b45486da86238fabe33e38306bd3118fe4af33fa880"
|
|
|
|
dependencies = [
|
|
|
|
"paste-impl",
|
|
|
|
"proc-macro-hack",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "paste"
|
2022-04-14 20:58:53 +03:00
|
|
|
version = "1.0.7"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-04-14 20:58:53 +03:00
|
|
|
checksum = "0c520e05135d6e763148b6426a837e239041653ba7becd2e538c076c738025fc"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "paste-impl"
|
|
|
|
version = "0.1.18"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d95a7db200b97ef370c8e6de0088252f7e0dfff7d047a28528e47456c0fc98b6"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro-hack",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "path-absolutize"
|
|
|
|
version = "3.0.13"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d3de4b40bd9736640f14c438304c09538159802388febb02c8abaae0846c1f13"
|
|
|
|
dependencies = [
|
|
|
|
"path-dedot",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "path-clean"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ecba01bf2678719532c5e3059e0b5f0811273d94b397088b82e3bd0a78c78fdd"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "path-dedot"
|
|
|
|
version = "3.0.17"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d611d5291372b3738a34ebf0d1f849e58b1dcc1101032f76a346eaa1f8ddbb5b"
|
|
|
|
dependencies = [
|
|
|
|
"once_cell",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "path-slash"
|
|
|
|
version = "0.1.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3cacbb3c4ff353b534a67fb8d7524d00229da4cb1dc8c79f4db96e375ab5b619"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pathdiff"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8835116a5c179084a830efb3adc117ab007512b535bc1a21c991d3b32a6b44dd"
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "pbkdf2"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "271779f35b581956db91a3e55737327a03aa051e90b1c47aeb189508533adfd7"
|
|
|
|
dependencies = [
|
|
|
|
"digest 0.10.3",
|
|
|
|
"hmac",
|
|
|
|
"password-hash",
|
|
|
|
"sha2",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "pem"
|
2022-06-01 14:44:40 +03:00
|
|
|
version = "1.0.2"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-06-01 14:44:40 +03:00
|
|
|
checksum = "e9a3b09a20e374558580a4914d3b7d89bd61b954a5a5e1dcbea98753addb1947"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"base64 0.13.0",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "percent-encoding"
|
|
|
|
version = "1.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "31010dd2e1ac33d5b46a5b413495239882813e0369f8ed8a5e266f173602f831"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "percent-encoding"
|
|
|
|
version = "2.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d4fd5641d01c8f18a23da7b6fe29298ff4b55afcccdf78973b24cf3175fee32e"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-project"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.0.10"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "58ad3879ad3baf4e44784bc6a718a8698867bb991f8ce24d1bcbe2cfb4c3a75e"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"pin-project-internal",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-project-internal"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.0.10"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "744b6f092ba29c3650faf274db506afd39944f48420f6c86b17cfe0ee1cb36bb"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-project-lite"
|
|
|
|
version = "0.1.12"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "257b64915a082f7811703966789728173279bdebb956b143dbcd23f6f970a777"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-project-lite"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.2.9"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "e0a7ae3ac2f1173085d398531c705756c94a4c56843785df85a60c1a0afac116"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-utils"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8b870d8c151b6f2fb93e84a13146138f05d02ed11c7e7c54f8826aaaf7c9f184"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pkg-config"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.3.25"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "1df8c4ec4b0627e53bdf214615ad287367e482558cf84b109250b37464dc03ae"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "platforms"
|
|
|
|
version = "3.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "86d1db500905601725f5c3629a5815a2ce7611fe063de279964b451f3edb3532"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "plotters"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "32a3fd9ec30b9749ce28cd91f255d569591cdf937fe280c312143e3c4bad6f2a"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
2022-02-16 15:58:02 +03:00
|
|
|
"plotters-backend",
|
|
|
|
"plotters-svg",
|
2021-11-10 16:36:08 +03:00
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "plotters-backend"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d88417318da0eaf0fdcdb51a0ee6c3bed624333bff8f946733049380be67ac1c"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "plotters-svg"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "521fa9638fa597e1dc53e9412a4f9cefb01187ee1f7413076f9e6749e2885ba9"
|
|
|
|
dependencies = [
|
|
|
|
"plotters-backend",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "polling"
|
|
|
|
version = "2.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "685404d509889fade3e86fe3a5803bca2ec09b0c0778d5ada6ec8bf7a8de5259"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"libc",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2022-02-16 15:58:02 +03:00
|
|
|
"wepoll-ffi",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "port_check"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f6519412c9e0d4be579b9f0618364d19cb434b324fc6ddb1b27b1e682c7105ed"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ppv-lite86"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.16"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "eb9f9e6e233e5c4a35559a617bf40a4ec447db2e84c20b55a6f83167b7e57872"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "predicates"
|
|
|
|
version = "1.0.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f49cfaf7fdaa3bfacc6fa3e7054e65148878354a5cfddcf661df4c851f8021df"
|
|
|
|
dependencies = [
|
|
|
|
"difference",
|
|
|
|
"float-cmp",
|
|
|
|
"normalize-line-endings",
|
|
|
|
"predicates-core",
|
|
|
|
"regex",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "predicates-core"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.0.3"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "da1c2388b1513e1b605fcec39a95e0a9e8ef088f71443ef37099fa9ae6673fcb"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "predicates-tree"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.0.5"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "4d86de6de25020a36c6d3643a86d9a6a9f552107c0559c60ea03551b5e16c032"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"predicates-core",
|
|
|
|
"termtree",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "pretty_env_logger"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "926d36b9553851b8b0005f1275891b392ee4d2d833852c417ed025477350fb9d"
|
|
|
|
dependencies = [
|
|
|
|
"env_logger",
|
|
|
|
"log 0.4.17",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-crate"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.1.3"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "e17d47ce914bf4de440332250b0edd23ce48c005f59fab39d3335866b114f11a"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"thiserror",
|
|
|
|
"toml",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-error"
|
|
|
|
version = "1.0.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "da25490ff9892aab3fcf7c36f08cfb902dd3e71ca0f9f9517bea02a73a5ce38c"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro-error-attr",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
"version_check 0.9.4",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-error-attr"
|
|
|
|
version = "1.0.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a1be40180e52ecc98ad80b184934baf3d0d29f979574e439af5a55274b35f869"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"version_check 0.9.4",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-hack"
|
|
|
|
version = "0.5.19"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "dbf0c48bc1d91375ae5c3cd81e3722dff1abcf81a30960240640d223f59fe0e5"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "proc-macro2"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "1.0.39"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "c54b25569025b7fc9651de43004ae593a75ad88543b17178aa5e1b9c4f15f56f"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"unicode-ident",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "prost"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.10.4"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "71adf41db68aa0daaefc69bb30bcd68ded9b9abaad5d1fbb6304c4fb390e083e"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"prost-derive",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "prost-derive"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7b670f45da57fb8542ebdbb6105a925fe571b67f9e7ed9f47a06a84e72b4e7cc"
|
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"itertools 0.10.3",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "prost-types"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2d0a014229361011dc8e69c8a1ec6c2e8d0f2af7c91e3ea3f5b2170298461e68"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"prost",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pulldown-cmark"
|
|
|
|
version = "0.9.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "34f197a544b0c9ab3ae46c359a7ec9cbbb5c7bf97054266fecb7ead794a181d6"
|
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
"getopts",
|
|
|
|
"memchr",
|
|
|
|
"unicase 2.6.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-16 15:28:50 +03:00
|
|
|
[[package]]
|
|
|
|
name = "qstring"
|
|
|
|
version = "0.7.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d464fae65fff2680baf48019211ce37aaec0c78e9264c84a3e484717f965104e"
|
|
|
|
dependencies = [
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "quick-error"
|
|
|
|
version = "1.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a1d01941d82fa2ab50be1e79e6714289dd7cde78eba4c074bc5a4374f650dfe0"
|
|
|
|
|
2022-06-01 14:44:40 +03:00
|
|
|
[[package]]
|
|
|
|
name = "quickcheck"
|
|
|
|
version = "1.0.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "588f6378e4dd99458b60ec275b4477add41ce4fa9f64dcba6f15adccb19b50d6"
|
|
|
|
dependencies = [
|
|
|
|
"rand 0.8.5",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "quote"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "1.0.18"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "a1feb54ed693b93a84e14094943b84b7c4eae204c512b7ccb95ab0c66d278ad1"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand"
|
|
|
|
version = "0.6.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6d71dacdc3c88c1fde3885a3be3fbab9f35724e6ce99467f7d9c5026132184ca"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 0.1.8",
|
2021-11-10 16:36:08 +03:00
|
|
|
"libc",
|
|
|
|
"rand_chacha 0.1.1",
|
|
|
|
"rand_core 0.4.2",
|
|
|
|
"rand_hc 0.1.0",
|
|
|
|
"rand_isaac",
|
|
|
|
"rand_jitter",
|
|
|
|
"rand_os",
|
|
|
|
"rand_pcg",
|
|
|
|
"rand_xorshift",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand"
|
|
|
|
version = "0.7.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6a6b1679d49b24bbfe0c803429aa1874472f50d9b363131f0e89fc356b544d03"
|
|
|
|
dependencies = [
|
|
|
|
"getrandom 0.1.16",
|
|
|
|
"libc",
|
|
|
|
"rand_chacha 0.2.2",
|
|
|
|
"rand_core 0.5.1",
|
|
|
|
"rand_hc 0.2.0",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rand"
|
|
|
|
version = "0.8.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "34af8d1a0e25924bc5b7c43c079c942339d8f0a8b57c39049bef581b46327404"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"rand_chacha 0.3.1",
|
|
|
|
"rand_core 0.6.3",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rand_chacha"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "556d3a1ca6600bfcbab7c7c91ccb085ac7fbbcd70e008a98742e7847f4f7bcef"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 0.1.8",
|
2021-11-10 16:36:08 +03:00
|
|
|
"rand_core 0.3.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_chacha"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f4c8ed856279c9737206bf725bf36935d8666ead7aa69b52be55af369d193402"
|
|
|
|
dependencies = [
|
|
|
|
"ppv-lite86",
|
|
|
|
"rand_core 0.5.1",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rand_chacha"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e6c10a63a0fa32252be49d21e7709d4d4baf8d231c2dbce1eaa8141b9b127d88"
|
|
|
|
dependencies = [
|
|
|
|
"ppv-lite86",
|
|
|
|
"rand_core 0.6.3",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rand_core"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7a6fdeb83b075e8266dcc8762c22776f6877a63111121f5f8c7411e5be7eed4b"
|
|
|
|
dependencies = [
|
|
|
|
"rand_core 0.4.2",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_core"
|
|
|
|
version = "0.4.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9c33a3c44ca05fa6f1807d8e6743f3824e8509beca625669633be0acbdf509dc"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_core"
|
|
|
|
version = "0.5.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "90bde5296fc891b0cef12a6d03ddccc162ce7b2aff54160af9338f8d40df6d19"
|
|
|
|
dependencies = [
|
|
|
|
"getrandom 0.1.16",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rand_core"
|
|
|
|
version = "0.6.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d34f1408f55294453790c48b2f1ebbb1c5b4b7563eb1f418bcfcfdbb06ebb4e7"
|
|
|
|
dependencies = [
|
|
|
|
"getrandom 0.2.6",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rand_distr"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "96977acbdd3a6576fb1d27391900035bf3863d4a16422973a409b488cf29ffb2"
|
|
|
|
dependencies = [
|
|
|
|
"rand 0.7.3",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_hc"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7b40677c7be09ae76218dc623efbf7b18e34bced3f38883af07bb75630a21bc4"
|
|
|
|
dependencies = [
|
|
|
|
"rand_core 0.3.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_hc"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ca3129af7b92a17112d59ad498c6f81eaf463253766b90396d39ea7a39d6613c"
|
|
|
|
dependencies = [
|
|
|
|
"rand_core 0.5.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_isaac"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ded997c9d5f13925be2a6fd7e66bf1872597f759fd9dd93513dd7e92e5a5ee08"
|
|
|
|
dependencies = [
|
|
|
|
"rand_core 0.3.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_jitter"
|
|
|
|
version = "0.1.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1166d5c91dc97b88d1decc3285bb0a99ed84b05cfd0bc2341bdf2d43fc41e39b"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"rand_core 0.4.2",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_os"
|
|
|
|
version = "0.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7b75f676a1e053fc562eafbb47838d67c84801e38fc1ba459e8f180deabd5071"
|
|
|
|
dependencies = [
|
|
|
|
"cloudabi",
|
|
|
|
"fuchsia-cprng",
|
|
|
|
"libc",
|
|
|
|
"rand_core 0.4.2",
|
|
|
|
"rdrand",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_pcg"
|
|
|
|
version = "0.1.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "abf9b09b01790cfe0364f52bf32995ea3c39f4d2dd011eac241d2914146d0b44"
|
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 0.1.8",
|
2021-11-10 16:36:08 +03:00
|
|
|
"rand_core 0.4.2",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_xorshift"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cbf7e9e623549b0e21f6e97cf8ecf247c1a8fd2e8a992ae265314300b2455d5c"
|
|
|
|
dependencies = [
|
|
|
|
"rand_core 0.3.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rawpointer"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "60a357793950651c4ed0f3f52338f53b2f809f32d83a07f72909fa13e4c6c1e3"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rayon"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "1.5.3"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "bd99e5772ead8baa5215278c9b15bf92087709e9c1b2d1f97cdb5a183c933a7d"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"autocfg 1.1.0",
|
|
|
|
"crossbeam-deque",
|
2021-11-10 16:36:08 +03:00
|
|
|
"either",
|
|
|
|
"rayon-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rayon-core"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "1.9.3"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "258bcdb5ac6dad48491bb2992db6b7cf74878b0384908af124823d118c99683f"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"crossbeam-channel",
|
|
|
|
"crossbeam-deque",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"crossbeam-utils 0.8.8",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num_cpus",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rdrand"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "678054eb77286b51581ba43620cc911abf02758c91f93f479767aed0f90458b2"
|
|
|
|
dependencies = [
|
|
|
|
"rand_core 0.3.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "redox_syscall"
|
|
|
|
version = "0.1.57"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "41cc0f7e4d5d4544e8861606a285bb08d3e70712ccc7d2b84d7c0ccfaf4b05ce"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "redox_syscall"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.2.13"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "62f25bc4c7e55e0b0b7a1d43fb893f4fa1361d0abe38b9ce4f323c2adfe6ef42"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "redox_users"
|
|
|
|
version = "0.4.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b033d837a7cf162d7993aded9304e30a83213c648b6e389db233191f891e5c2b"
|
|
|
|
dependencies = [
|
|
|
|
"getrandom 0.2.6",
|
|
|
|
"redox_syscall 0.2.13",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "regex"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "1.5.6"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "d83f127d94bdbcda4c8cc2e50f6f84f4b611f69c902699ca385a39c3a75f9ff1"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"aho-corasick",
|
|
|
|
"memchr",
|
|
|
|
"regex-syntax",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "regex-automata"
|
|
|
|
version = "0.1.10"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6c230d73fb8d8c1b9c0b3135c5142a8acee3a0558fb8db5cf1cb65f8d7862132"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"regex-syntax",
|
|
|
|
]
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "regex-syntax"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "0.6.26"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "49b3de9ec5dc0a3417da371aab17d729997c15010e7fd24ff707773a33bddb64"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "remove_dir_all"
|
|
|
|
version = "0.5.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3acd125665422973a33ac9d3dd2df85edad0f4ae9b00dafb1a05e43a9f5ef8e7"
|
|
|
|
dependencies = [
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "reqwest"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.10.10"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "0718f81a8e14c4dbb3b34cf23dc6aaf9ab8a0dfec160c534b3dbca1aaa21f47c"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"base64 0.13.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 0.5.6",
|
|
|
|
"encoding_rs",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"http",
|
2022-05-23 05:16:04 +03:00
|
|
|
"http-body 0.3.1",
|
2021-11-10 16:36:08 +03:00
|
|
|
"hyper 0.13.10",
|
|
|
|
"hyper-tls",
|
|
|
|
"ipnet",
|
|
|
|
"js-sys",
|
|
|
|
"lazy_static",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
"mime 0.3.16",
|
|
|
|
"mime_guess",
|
|
|
|
"native-tls",
|
|
|
|
"percent-encoding 2.1.0",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"pin-project-lite 0.2.9",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
|
|
|
"serde_urlencoded",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
2021-11-10 16:36:08 +03:00
|
|
|
"tokio-tls 0.3.1",
|
|
|
|
"url 2.2.2",
|
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-futures",
|
2021-11-10 16:36:08 +03:00
|
|
|
"web-sys",
|
2022-05-23 05:16:04 +03:00
|
|
|
"winreg 0.7.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "reqwest"
|
|
|
|
version = "0.11.10"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "46a1f7aa4f35e5e8b4160449f51afc758f0ce6454315a9fa7d0d113e958c41eb"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.13.0",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"encoding_rs",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"h2 0.3.13",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"hyper-rustls 0.23.0",
|
|
|
|
"ipnet",
|
|
|
|
"js-sys",
|
|
|
|
"lazy_static",
|
|
|
|
"log 0.4.17",
|
|
|
|
"mime 0.3.16",
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
"rustls 0.20.6",
|
|
|
|
"rustls-pemfile",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"serde_urlencoded",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-rustls 0.23.4",
|
|
|
|
"tokio-util 0.6.10",
|
|
|
|
"url 2.2.2",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"wasm-bindgen-futures",
|
|
|
|
"web-sys",
|
|
|
|
"webpki-roots",
|
|
|
|
"winreg 0.10.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "retain_mut"
|
|
|
|
version = "0.1.9"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4389f1d5789befaf6029ebd9f7dac4af7f7e3d61b69d4f30e2ac02b57e7712b0"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ring"
|
|
|
|
version = "0.16.20"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3053cf52e236a3ed746dfc745aa9cacf1b791d846bdaf412f60a8d7d6e17c8fc"
|
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"libc",
|
|
|
|
"once_cell",
|
|
|
|
"spin 0.5.2",
|
|
|
|
"untrusted",
|
|
|
|
"web-sys",
|
|
|
|
"winapi 0.3.9",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustc-demangle"
|
|
|
|
version = "0.1.21"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7ef03e0a2b150c7a90d01faf6254c9c48a41e95fb2a8c2ac1c6f0d2b9aefc342"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustc-hash"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "08d43f7aa6b08d49f382cde6a7982047c3426db949b1424bc4b7ec9ae12c6ce2"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustc_version"
|
|
|
|
version = "0.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "138e3e0acb6c9fb258b19b67cb8abd63c00679d2851805ea151465464fe9030a"
|
|
|
|
dependencies = [
|
|
|
|
"semver 0.9.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustc_version"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bfa0f585226d2e68097d4f95d113b15b83a82e819ab25717ec0590d9584ef366"
|
|
|
|
dependencies = [
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"semver 1.0.9",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rustls"
|
|
|
|
version = "0.19.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "35edb675feee39aec9c99fa5ff985081995a06d594114ae14cbe797ad7b7a6d7"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.13.0",
|
|
|
|
"log 0.4.17",
|
|
|
|
"ring",
|
|
|
|
"sct 0.6.1",
|
|
|
|
"webpki 0.21.4",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustls"
|
|
|
|
version = "0.20.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5aab8ee6c7097ed6057f43c187a62418d0c05a4bd5f18b3571db50ee0f9ce033"
|
|
|
|
dependencies = [
|
|
|
|
"log 0.4.17",
|
|
|
|
"ring",
|
|
|
|
"sct 0.7.0",
|
|
|
|
"webpki 0.22.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustls-native-certs"
|
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5a07b7c1885bd8ed3831c289b7870b13ef46fe0e856d288c30d9cc17d75a2092"
|
|
|
|
dependencies = [
|
|
|
|
"openssl-probe",
|
|
|
|
"rustls 0.19.1",
|
|
|
|
"schannel",
|
|
|
|
"security-framework",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustls-pemfile"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1ee86d63972a7c661d1536fefe8c3c8407321c3df668891286de28abcd087360"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.13.0",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "rustversion"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.0.6"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "f2cc38e8fa666e2de3c4aba7edeb5ffc5246c1c2ed0e3d17e560aeeba736b23f"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ryu"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "1.0.10"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "f3f6f92acf49d1b98f7a81226834412ada05458b7364277387724a237f062695"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "safemem"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ef703b7cb59335eae2eb93ceb664c0eb7ea6bf567079d843e09420219668e072"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "same-file"
|
|
|
|
version = "1.0.6"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "93fc1dc3aaa9bfed95e02e6eadabb4baf7e3078b0bd1b4d7b6b0b68378900502"
|
|
|
|
dependencies = [
|
|
|
|
"winapi-util",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "schannel"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "0.1.20"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "88d6731146462ea25d9244b2ed5fd1d716d25c52e4d54aa4fb0f3c4e9854dbe2"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"lazy_static",
|
2022-05-23 05:16:04 +03:00
|
|
|
"windows-sys",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "scoped-tls"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ea6a9290e3c9cf0f18145ef7ffa62d68ee0bf5fcd651017e586dc7fd5da448c2"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "scopeguard"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sct"
|
|
|
|
version = "0.6.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b362b83898e0e69f38515b82ee15aa80636befe47c3b6d3d89a911e78fc228ce"
|
|
|
|
dependencies = [
|
|
|
|
"ring",
|
|
|
|
"untrusted",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sct"
|
|
|
|
version = "0.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d53dcdb7c9f8158937a7981b48accfd39a43af418591a5d008c7b22b5e1b7ca4"
|
|
|
|
dependencies = [
|
|
|
|
"ring",
|
|
|
|
"untrusted",
|
|
|
|
]
|
|
|
|
|
2022-06-01 14:44:40 +03:00
|
|
|
[[package]]
|
|
|
|
name = "secrecy"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9bd1c54ea06cfd2f6b63219704de0b9b4f72dcc2b8fdef820be6cd799780e91e"
|
|
|
|
dependencies = [
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "security-framework"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "2.6.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "2dc14f172faf8a0194a3aded622712b0de276821addc574fa54fc0a1167e10dc"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bitflags",
|
|
|
|
"core-foundation",
|
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
|
|
|
"security-framework-sys",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "security-framework-sys"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "2.6.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "0160a13a177a45bfb43ce71c01580998474f556ad854dcbca936dd2841a5c556"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "semver"
|
|
|
|
version = "0.9.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "1d7eb9ef2c18661902cc47e535f9bc51b78acd254da71d375c2f6720d9a40403"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"semver-parser",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "semver"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.0.9"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "8cb243bdfdb5936c8dc3c45762a19d12ab4550cdc753bc247637d4ec35a040fd"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "semver-parser"
|
|
|
|
version = "0.7.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "388a1df253eca08550bef6c72392cfe7c30914bf41df5269b68cbd6ff8f570a3"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "serde"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.0.137"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "61ea8d54c77f8315140a05f4c7237403bf38b72704d031543aa1d16abbf517d1"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde_derive",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "serde_cbor"
|
|
|
|
version = "0.11.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "2bef2ebfde456fb76bbcf9f59315333decc4fda0b2b44b420243c11e0f5ec1f5"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"half",
|
|
|
|
"serde",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "serde_derive"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.0.137"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "1f26faba0c3959972377d3b2d306ee9f71faee9714294e41bb777f83f88578be"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "serde_json"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.0.81"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "9b7ce2b32a1aed03c558dc61a5cd328f15aff2dbc17daad8fb8af04d2100e15c"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"itoa 1.0.2",
|
2021-11-10 16:36:08 +03:00
|
|
|
"ryu",
|
|
|
|
"serde",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "serde_path_to_error"
|
|
|
|
version = "0.1.7"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d7868ad3b8196a8a0aea99a8220b124278ee5320a55e4fde97794b6f85b1a377"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serde_qs"
|
|
|
|
version = "0.8.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c7715380eec75f029a4ef7de39a9200e0a63823176b759d055b613f5a87df6a6"
|
|
|
|
dependencies = [
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"serde",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "serde_urlencoded"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.7.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "d3491c14715ca2294c4d6a88f15e84739788c1d030eed8c110436aafdaa2f3fd"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"form_urlencoded",
|
2022-05-23 05:16:04 +03:00
|
|
|
"itoa 1.0.2",
|
2022-02-16 15:58:02 +03:00
|
|
|
"ryu",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "serde_yaml"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "0.8.24"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "707d15895415db6628332b737c838b88c598522e4dc70647e59b72312924aebc"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"indexmap",
|
|
|
|
"ryu",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
|
|
|
"yaml-rust",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sha-1"
|
|
|
|
version = "0.10.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "028f48d513f9678cda28f6e4064755b3fbb2af6acd672f2c209b62323f7aea0f"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"cpufeatures",
|
|
|
|
"digest 0.10.3",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "sha1"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.6.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c1da05c97445caa12d05e848c4a4fcbbea29e748ac28f7e80e9b010392063770"
|
|
|
|
dependencies = [
|
|
|
|
"sha1_smol",
|
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sha1"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c77f4e7f65455545c2153c1253d25056825e77ee2533f0e41deb65a93a34852f"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"cpufeatures",
|
|
|
|
"digest 0.10.3",
|
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sha1_smol"
|
|
|
|
version = "1.0.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "ae1a47186c03a32177042e55dbc5fd5aee900b8e0069a8d70fba96a9375cd012"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sha2"
|
|
|
|
version = "0.10.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "55deaec60f81eefe3cce0dc50bda92d6d8e88f2a27df7c5033b42afeb1ed2676"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"cpufeatures",
|
|
|
|
"digest 0.10.3",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sha3"
|
|
|
|
version = "0.8.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "dd26bc0e7a2e3a7c959bc494caf58b72ee0c71d67704e9520f736ca7e4853ecf"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"block-buffer 0.7.3",
|
2021-11-10 16:36:08 +03:00
|
|
|
"byte-tools",
|
2022-05-23 05:16:04 +03:00
|
|
|
"digest 0.8.1",
|
2021-11-10 16:36:08 +03:00
|
|
|
"keccak",
|
2022-05-26 05:14:11 +03:00
|
|
|
"opaque-debug 0.2.3",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-17 06:13:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sharded-slab"
|
|
|
|
version = "0.1.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "900fba806f70c630b0a382d0d825e17a0f19fcd059a2ade1ff237bcddf446b31"
|
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "shrinkwraprs"
|
|
|
|
version = "0.2.3"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "83695fde96cbe9e08f0e4eb96b1b56fdbd44f2098ee27462dda964c7745fddc7"
|
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
"itertools 0.8.2",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "shrinkwraprs"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e63e6744142336dfb606fe2b068afa2e1cca1ee6a5d8377277a92945d81fa331"
|
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
"itertools 0.8.2",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "signal-hook-registry"
|
|
|
|
version = "1.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e51e73328dc4ac0c7ccbda3a494dfa03df1de2f46018127f60c693f2648455b0"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "simba"
|
|
|
|
version = "0.1.5"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "fb931b1367faadea6b1ab1c306a860ec17aaa5fa39f367d0c744e69d971a1fb2"
|
|
|
|
dependencies = [
|
|
|
|
"approx 0.3.2",
|
|
|
|
"num-complex 0.2.4",
|
|
|
|
"num-traits",
|
|
|
|
"paste 0.1.18",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "simba"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5132a955559188f3d13c9ba831e77c802ddc8782783f050ed0c52f5988b95f4c"
|
|
|
|
dependencies = [
|
|
|
|
"approx 0.4.0",
|
|
|
|
"num-complex 0.3.1",
|
|
|
|
"num-traits",
|
2022-04-14 20:58:53 +03:00
|
|
|
"paste 1.0.7",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "simple_asn1"
|
2022-06-01 14:44:40 +03:00
|
|
|
version = "0.6.1"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-06-01 14:44:40 +03:00
|
|
|
checksum = "4a762b1c38b9b990c694b9c2f8abe3372ce6a9ceaae6bca39cfc46e054f45745"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
2022-06-01 14:44:40 +03:00
|
|
|
"num-bigint",
|
2022-05-23 05:16:04 +03:00
|
|
|
"num-traits",
|
2022-06-01 14:44:40 +03:00
|
|
|
"thiserror",
|
|
|
|
"time 0.3.9",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "slab"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.4.6"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "eb703cfe953bccee95685111adeedb76fabe4e97549a58d16f03ea7b9367bb32"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "smallvec"
|
|
|
|
version = "0.6.14"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b97fcaeba89edba30f044a10c6a3cc39df9c3f17d7cd829dd1446cab35f890e0"
|
|
|
|
dependencies = [
|
|
|
|
"maybe-uninit",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "smallvec"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.8.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "f2dd574626839106c320a323308629dcb1acfc96e32a8cba364ddc61ac23ee83"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "snafu"
|
|
|
|
version = "0.7.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5177903bf45656592d9eb5c0e22f408fc023aae51dbe2088889b71633ba451f2"
|
|
|
|
dependencies = [
|
|
|
|
"backtrace",
|
|
|
|
"doc-comment",
|
2022-05-26 05:14:11 +03:00
|
|
|
"snafu-derive",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "snafu-derive"
|
|
|
|
version = "0.7.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "410b26ed97440d90ced3e2488c868d56a86e2064f5d7d6f417909b286afe25e5"
|
|
|
|
dependencies = [
|
|
|
|
"heck 0.4.0",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "socket2"
|
|
|
|
version = "0.3.19"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "122e570113d28d773067fab24266b66753f6ea915758651696b6e35e49f88d6e"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"libc",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2022-02-16 15:58:02 +03:00
|
|
|
name = "socket2"
|
|
|
|
version = "0.4.4"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "66d72b759436ae32898a2af0a14218dbf55efde3feeb170eb623637db85ee1e0"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-01-11 15:31:43 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sourcemap"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "6.0.2"
|
2022-01-11 15:31:43 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "a2ca89636b276071e7276488131f531dbf43ad1c19bc4bd5a04f6a0ce1ddc138"
|
2022-01-11 15:31:43 +03:00
|
|
|
dependencies = [
|
|
|
|
"base64 0.11.0",
|
|
|
|
"if_chain",
|
|
|
|
"lazy_static",
|
|
|
|
"regex",
|
|
|
|
"rustc_version 0.2.3",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"url 2.2.2",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "span-tree"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ast",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-data-structures",
|
2021-11-10 16:36:08 +03:00
|
|
|
"enso-prelude",
|
2022-03-21 21:09:56 +03:00
|
|
|
"enso-profiler",
|
2021-11-25 13:45:42 +03:00
|
|
|
"enso-text",
|
2021-11-10 16:36:08 +03:00
|
|
|
"failure",
|
|
|
|
"parser",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-test",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "spin"
|
|
|
|
version = "0.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6e63cff320ae2c57904679ba7cb63280a3dc4613885beafb148ee7bf9aa9042d"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "spin"
|
|
|
|
version = "0.9.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c530c2b0d0bf8b69304b39fe2001993e267461948b890cd037d8ad4293fa1a0d"
|
|
|
|
dependencies = [
|
|
|
|
"lock_api 0.4.7",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "stable_deref_trait"
|
|
|
|
version = "1.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a8f112729512f8e442d81f95a8a7ddf2b7c6b8a1a6f509a95864142b30cab2d3"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "strsim"
|
|
|
|
version = "0.10.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "73473c0e59e6d5812c5dfe2a064a6444949f089e20eec9a2e5506596494e4623"
|
|
|
|
|
2022-04-19 14:30:29 +03:00
|
|
|
[[package]]
|
|
|
|
name = "strum"
|
|
|
|
version = "0.24.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e96acfc1b70604b8b2f1ffa4c57e59176c7dbb05d556c71ecd2f5498a1dee7f8"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
2022-05-26 05:14:11 +03:00
|
|
|
"strum_macros",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2022-04-19 14:30:29 +03:00
|
|
|
[[package]]
|
|
|
|
name = "strum_macros"
|
|
|
|
version = "0.24.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6878079b17446e4d3eba6192bb0a2950d5b14f0ed8424b852310e5a94345d0ef"
|
|
|
|
dependencies = [
|
2022-05-23 05:16:04 +03:00
|
|
|
"heck 0.4.0",
|
2022-04-19 14:30:29 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"rustversion",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "subtle"
|
|
|
|
version = "2.4.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6bdef32e8150c2a081110b42772ffe7d7c9032b606bc226c8260fd97e0976601"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "symlink"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a7973cce6668464ea31f176d85b13c7ab3bba2cb3b77a2ed26abd7801688010a"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "syn"
|
2022-05-23 05:16:04 +03:00
|
|
|
version = "1.0.95"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-23 05:16:04 +03:00
|
|
|
checksum = "fbaf6116ab8924f39d52792136fb74fd60a80194cf1b1c6ffa6453eef1c3f942"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2022-05-23 05:16:04 +03:00
|
|
|
"unicode-ident",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sync_wrapper"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "20518fe4a4c9acf048008599e464deb21beeae3d3578418951a189c235a7a9a8"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "synstructure"
|
|
|
|
version = "0.12.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f36bdaa60a83aca3921b5259d5400cbf5e90fc51931376a9bd4a0eb79aa7210f"
|
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
2022-02-11 15:19:02 +03:00
|
|
|
"unicode-xid",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "sysinfo"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "0.23.13"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "3977ec2e0520829be45c8a2df70db2bf364714d8a748316a10c3c35d4d2b01c9"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
|
|
|
"ntapi",
|
|
|
|
"once_cell",
|
|
|
|
"rayon",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tar"
|
|
|
|
version = "0.4.38"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4b55807c0344e1e6c04d7c965f5289c39a8d94ae23ed5c0b57aabac549f871c6"
|
|
|
|
dependencies = [
|
|
|
|
"filetime",
|
|
|
|
"libc",
|
|
|
|
"xattr",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tempfile"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "3.3.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "5cdb1ef4eaeeaddc8fbd371e5017057064af0911902ef36b39801f67cc6d79e4"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if 1.0.0",
|
2022-02-16 15:58:02 +03:00
|
|
|
"fastrand",
|
2021-11-10 16:36:08 +03:00
|
|
|
"libc",
|
2022-05-23 05:16:04 +03:00
|
|
|
"redox_syscall 0.2.13",
|
|
|
|
"remove_dir_all",
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "termcolor"
|
|
|
|
version = "1.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bab24d30b911b2376f3a13cc2cd443142f0c81dda04c118693e35b3835757755"
|
|
|
|
dependencies = [
|
|
|
|
"winapi-util",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "terminal_size"
|
|
|
|
version = "0.1.17"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "633c1a546cee861a1a6d0dc69ebeca693bf4296661ba7852b9d21d159e0506df"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
2021-11-10 16:36:08 +03:00
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "termtree"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.4"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "507e9898683b6c43a9aa55b64259b721b52ba226e0f3779137e50ad114a4c90b"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "textwrap"
|
|
|
|
version = "0.11.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d326610f408c7a4eb6f51c37c330e496b08506c9457c9d34287ecc38809fb060"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"unicode-width",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "textwrap"
|
|
|
|
version = "0.15.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b1141d4d61095b28419e22cb0bbf02755f5e54e0526f97f1e3d1d160e60885fb"
|
|
|
|
dependencies = [
|
|
|
|
"terminal_size",
|
|
|
|
]
|
|
|
|
|
2021-05-14 15:08:39 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "thiserror"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.0.31"
|
2021-05-14 15:08:39 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "bd829fe32373d27f76265620b5309d0340cb8550f523c1dda251d6298069069a"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"thiserror-impl",
|
|
|
|
]
|
2021-05-14 15:08:39 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "thiserror-impl"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.0.31"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "0396bc89e626244658bef819e22d0cc459e795a5ebe878e6ec336d1674a8d79a"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-17 06:13:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "thread_local"
|
|
|
|
version = "1.1.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5516c27b78311c50bf42c071425c560ac799b11c30b31f87e3081965fe5e0180"
|
|
|
|
dependencies = [
|
|
|
|
"once_cell",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "time"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.1.44"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "6db9e6914ab8b1ae1c260a4ae7a49b6c5611b40328a735b21862567685e73255"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"libc",
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"wasi 0.10.0+wasi-snapshot-preview1",
|
2021-11-10 16:36:08 +03:00
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "time"
|
|
|
|
version = "0.3.9"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c2702e08a7a860f005826c6815dcac101b19b5eb330c27fe4a5928fec1d20ddd"
|
|
|
|
dependencies = [
|
2022-05-26 05:14:11 +03:00
|
|
|
"itoa 1.0.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"libc",
|
|
|
|
"num_threads",
|
2022-06-01 14:44:40 +03:00
|
|
|
"quickcheck",
|
2022-05-26 05:14:11 +03:00
|
|
|
"time-macros",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "time-macros"
|
|
|
|
version = "0.2.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "42657b1a6f4d817cda8e7a0ace261fe0cc946cf3a80314390b22cc61ae080792"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tinytemplate"
|
|
|
|
version = "1.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "be4d6b5f19ff7664e8c98d03e2139cb510db9b0a60b55f8e8709b689d939b6bc"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tinyvec"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.6.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "87cc5ceb3875bb20c2890005a4e226a4651264a5c75edb2421b52861a0a0cb50"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"tinyvec_macros",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tinyvec_macros"
|
|
|
|
version = "0.1.0"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "cda74da7e1a664f795bb1f8a87ec406fb89a02522cf6e50620d016add6dbbf5c"
|
2021-10-30 16:04:07 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio"
|
|
|
|
version = "0.2.25"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "6703a273949a90131b290be1fe7b039d0fc884aa1935860dfcbe056f28cd8092"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 0.5.6",
|
|
|
|
"fnv",
|
|
|
|
"futures-core",
|
|
|
|
"iovec",
|
|
|
|
"lazy_static",
|
|
|
|
"memchr",
|
2022-05-23 05:16:04 +03:00
|
|
|
"mio 0.6.23",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num_cpus",
|
|
|
|
"pin-project-lite 0.1.12",
|
|
|
|
"slab",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-macros 0.2.6",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio"
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
version = "1.19.2"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
checksum = "c51a52ed6686dd62c320f9b89299e9dfb46f730c7a48e635c19f21d116cb1439"
|
2022-05-23 05:16:04 +03:00
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"libc",
|
|
|
|
"memchr",
|
|
|
|
"mio 0.8.3",
|
|
|
|
"num_cpus",
|
|
|
|
"once_cell",
|
|
|
|
"parking_lot 0.12.0",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
"signal-hook-registry",
|
|
|
|
"socket2 0.4.4",
|
|
|
|
"tokio-macros 1.7.0",
|
|
|
|
"tracing",
|
|
|
|
"winapi 0.3.9",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-codec"
|
|
|
|
version = "0.1.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "25b2998660ba0e70d18684de5d06b70b70a3a747469af9dea7618cc59e75976b"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 0.4.12",
|
|
|
|
"futures 0.1.31",
|
|
|
|
"tokio-io",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-executor"
|
|
|
|
version = "0.1.10"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "fb2d1b8f4548dbf5e1f7818512e9c406860678f29c300cdf0ebac72d1a3a1671"
|
|
|
|
dependencies = [
|
|
|
|
"crossbeam-utils 0.7.2",
|
|
|
|
"futures 0.1.31",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-io"
|
|
|
|
version = "0.1.13"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "57fc868aae093479e3131e3d165c93b1c7474109d13c90ec0dda2a1bbfff0674"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 0.4.12",
|
|
|
|
"futures 0.1.31",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tokio-io-timeout"
|
|
|
|
version = "1.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "30b74022ada614a1b4834de765f9bb43877f910cc8ce4be40e89042c9223a8bf"
|
|
|
|
dependencies = [
|
|
|
|
"pin-project-lite 0.2.9",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-macros"
|
|
|
|
version = "0.2.6"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "e44da00bfc73a25f814cd8d7e57a68a5c31b74b3152a0a1d1f590c97ed06265a"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-10 16:36:08 +03:00
|
|
|
"syn",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tokio-macros"
|
|
|
|
version = "1.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b557f72f448c511a979e2564e55d74e6c4432fc96ff4f6241bc6bded342643b7"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-reactor"
|
|
|
|
version = "0.1.12"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "09bc590ec4ba8ba87652da2068d150dcada2cfa2e07faae270a5e0409aa51351"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"crossbeam-utils 0.7.2",
|
|
|
|
"futures 0.1.31",
|
|
|
|
"lazy_static",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2022-05-23 05:16:04 +03:00
|
|
|
"mio 0.6.23",
|
2021-11-10 16:36:08 +03:00
|
|
|
"num_cpus",
|
2022-05-23 05:16:04 +03:00
|
|
|
"parking_lot 0.9.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"slab",
|
|
|
|
"tokio-executor",
|
|
|
|
"tokio-io",
|
|
|
|
"tokio-sync",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tokio-rustls"
|
|
|
|
version = "0.22.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bc6844de72e57df1980054b38be3a9f4702aba4858be64dd700181a8a6d0e1b6"
|
|
|
|
dependencies = [
|
|
|
|
"rustls 0.19.1",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"webpki 0.21.4",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio-rustls"
|
|
|
|
version = "0.23.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c43ee83903113e03984cb9e5cebe6c04a5116269e900e3ddba8f068a62adda59"
|
|
|
|
dependencies = [
|
|
|
|
"rustls 0.20.6",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"webpki 0.22.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio-stream"
|
|
|
|
version = "0.1.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "50145484efff8818b5ccd256697f36863f587da82cf8b409c53adf1e840798e3"
|
|
|
|
dependencies = [
|
|
|
|
"futures-core",
|
|
|
|
"pin-project-lite 0.2.9",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-sync"
|
|
|
|
version = "0.1.8"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "edfe50152bc8164fcc456dab7891fa9bf8beaf01c5ee7e1dd43a397c3cf87dee"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"fnv",
|
|
|
|
"futures 0.1.31",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-tcp"
|
|
|
|
version = "0.1.4"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "98df18ed66e3b72e742f185882a9e201892407957e45fbff8da17ae7a7c51f72"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"bytes 0.4.12",
|
|
|
|
"futures 0.1.31",
|
|
|
|
"iovec",
|
2022-05-23 05:16:04 +03:00
|
|
|
"mio 0.6.23",
|
2021-11-10 16:36:08 +03:00
|
|
|
"tokio-io",
|
|
|
|
"tokio-reactor",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-tls"
|
|
|
|
version = "0.2.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "354b8cd83825b3c20217a9dc174d6a0c67441a2fae5c41bcb1ea6679f6ae0f7c"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"futures 0.1.31",
|
|
|
|
"native-tls",
|
|
|
|
"tokio-io",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-tls"
|
|
|
|
version = "0.3.1"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "9a70f4fcd7b3b24fb194f837560168208f669ca8cb70d0c4b862944452396343"
|
2021-10-30 16:04:07 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"native-tls",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tokio-util"
|
|
|
|
version = "0.3.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "be8242891f2b6cbef26a2d7e8605133c2c554cd35b3e4948ea892d6d68436499"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 0.5.6",
|
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
"pin-project-lite 0.1.12",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio 0.2.25",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio-util"
|
|
|
|
version = "0.6.10"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "36943ee01a6d67977dd3f84a5a1d2efeb4ada3a1ae771cadfaa535d9d9fc6507"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
|
|
|
"log 0.4.17",
|
|
|
|
"pin-project-lite 0.2.9",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio-util"
|
|
|
|
version = "0.7.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f988a1a1adc2fb21f9c12aa96441da33a1728193ae0b95d2be22dbd17fcb4e5c"
|
|
|
|
dependencies = [
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"futures-core",
|
2022-05-26 05:14:11 +03:00
|
|
|
"futures-io",
|
2022-05-23 05:16:04 +03:00
|
|
|
"futures-sink",
|
2022-05-26 05:14:11 +03:00
|
|
|
"futures-util",
|
2022-05-23 05:16:04 +03:00
|
|
|
"pin-project-lite 0.2.9",
|
2022-05-26 05:14:11 +03:00
|
|
|
"slab",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tracing",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "toml"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.5.9"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "8d82e1a7758622a465f8cee077614c73484dac5b836c02ff6a40d5d1010324d7"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tonic"
|
|
|
|
version = "0.7.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5be9d60db39854b30b835107500cf0aca0b0d14d6e1c3de124217c23a29c2ddb"
|
|
|
|
dependencies = [
|
|
|
|
"async-stream",
|
|
|
|
"async-trait",
|
|
|
|
"axum",
|
|
|
|
"base64 0.13.0",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"h2 0.3.13",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"hyper-timeout",
|
|
|
|
"percent-encoding 2.1.0",
|
|
|
|
"pin-project",
|
|
|
|
"prost",
|
|
|
|
"prost-derive",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-stream",
|
|
|
|
"tokio-util 0.7.2",
|
|
|
|
"tower",
|
|
|
|
"tower-layer",
|
|
|
|
"tower-service",
|
|
|
|
"tracing",
|
|
|
|
"tracing-futures",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tower"
|
|
|
|
version = "0.4.12"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9a89fd63ad6adf737582df5db40d286574513c69a11dac5214dc3b5603d6713e"
|
|
|
|
dependencies = [
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"indexmap",
|
|
|
|
"pin-project",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
"rand 0.8.5",
|
|
|
|
"slab",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tokio-util 0.7.2",
|
|
|
|
"tower-layer",
|
|
|
|
"tower-service",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tower-http"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7d342c6d58709c0a6d48d48dabbb62d4ef955cf5f0f3bbfd845838e7ae88dbae"
|
|
|
|
dependencies = [
|
|
|
|
"bitflags",
|
|
|
|
"bytes 1.1.0",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"http",
|
|
|
|
"http-body 0.4.5",
|
|
|
|
"http-range-header",
|
|
|
|
"pin-project-lite 0.2.9",
|
|
|
|
"tower",
|
|
|
|
"tower-layer",
|
|
|
|
"tower-service",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tower-layer"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "343bc9466d3fe6b0f960ef45960509f84480bf4fd96f92901afe7ff3df9d3a62"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tower-service"
|
|
|
|
version = "0.3.1"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "360dfd1d6d30e05fda32ace2c8c70e9c0a9da713275777f5a4dbb8a1893930c6"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tracing"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.1.34"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "5d0ecdcb44a79f0fe9844f0c4f33a342cbcbb5117de8001e6ba0dc2351327d09"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"cfg-if 1.0.0",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
|
|
|
"pin-project-lite 0.2.9",
|
2022-05-17 06:13:20 +03:00
|
|
|
"tracing-attributes",
|
2021-11-10 16:36:08 +03:00
|
|
|
"tracing-core",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-17 06:13:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tracing-attributes"
|
|
|
|
version = "0.1.21"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cc6b8ad3567499f98a1db7a752b07a7c8c7c7c34c332ec00effb2b0027974b7c"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tracing-core"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.1.26"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "f54c8ca710e81886d498c2fd3331b56c93aa248d49de2222ad2742247c60072f"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"lazy_static",
|
2022-05-17 06:13:20 +03:00
|
|
|
"valuable",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "tracing-futures"
|
|
|
|
version = "0.2.5"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "97d095ae15e245a057c8e8451bab9b3ee1e1f68e9ba2b4fbc18d0ac5237835f2"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"pin-project",
|
|
|
|
"tracing",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2022-05-17 06:13:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "tracing-log"
|
|
|
|
version = "0.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "78ddad33d2d10b1ed7eb9d1f518a5674713876e97e5bb9b7345a7984fbb4f922"
|
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"log 0.4.17",
|
|
|
|
"tracing-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-subscriber"
|
|
|
|
version = "0.3.11"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4bc28f93baff38037f64e6f43d34cfa1605f27a49c34e8a04c5e78b0babf2596"
|
|
|
|
dependencies = [
|
|
|
|
"ansi_term",
|
2022-05-23 05:16:04 +03:00
|
|
|
"lazy_static",
|
|
|
|
"matchers",
|
|
|
|
"regex",
|
2022-05-17 06:13:20 +03:00
|
|
|
"sharded-slab",
|
|
|
|
"smallvec 1.8.0",
|
|
|
|
"thread_local",
|
2022-05-23 05:16:04 +03:00
|
|
|
"tracing",
|
2022-05-17 06:13:20 +03:00
|
|
|
"tracing-core",
|
|
|
|
"tracing-log",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-wasm"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4575c663a174420fa2d78f4108ff68f65bf2fbb7dd89f33749b6e826b3626e07"
|
|
|
|
dependencies = [
|
|
|
|
"tracing",
|
|
|
|
"tracing-subscriber",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2021-05-14 15:08:39 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "traitobject"
|
|
|
|
version = "0.1.0"
|
2021-05-14 15:08:39 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "efd1f82c56340fdf16f2a953d7bda4f8fdffba13d93b00844c25572110b26079"
|
2021-05-14 15:08:39 +03:00
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "try-lock"
|
|
|
|
version = "0.2.3"
|
2021-05-14 15:08:39 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "59547bce71d9c38b83d9c0e92b6066c4253371f15005def0c30d9657f50c7642"
|
2021-05-14 15:08:39 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "typeable"
|
|
|
|
version = "0.1.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1410f6f91f21d1612654e7cc69193b0334f909dcf2c790c4826254fbb86f8887"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "typenum"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.15.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "dcf81ac59edc17cc8697ff311e8f5ef2d99fcbd9817b34cec66f90b6c3dfd987"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicase"
|
|
|
|
version = "1.4.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "7f4765f83163b74f957c797ad9253caf97f103fb064d3999aea9568d09fc8a33"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"version_check 0.1.5",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "unicase"
|
|
|
|
version = "2.6.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "50f37be617794602aabbeee0be4f259dc1778fabe05e2d67ee8f79326d5cb4f6"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"version_check 0.9.4",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2021-11-10 16:36:08 +03:00
|
|
|
name = "unicode-bidi"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.3.8"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "099b7128301d285f79ddd55b9a83d5e6b9e97c92e0ea0daebee7263e932de992"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "unicode-ident"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d22af068fba1eb5edcb4aea19d382b2a3deb4c8f9d475c589b6ada9e0fd493ee"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "unicode-normalization"
|
|
|
|
version = "0.1.19"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "d54590932941a9e9266f0832deed84ebe1bf2e4c9e4a3554d393d18f5e854bf9"
|
|
|
|
dependencies = [
|
|
|
|
"tinyvec",
|
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicode-segmentation"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "1.9.0"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "7e8820f5d777f6224dc4be3632222971ac30164d4a258d595640799554ebfd99"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicode-width"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "0.1.9"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "3ed742d4ea2bd1176e236172c8429aaf54486e7ac098db29ffe6529e0ce50973"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicode-xid"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "0.2.3"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "957e51f3646910546462e67d5f7599b9e4fb8acdd304b087a6494730f9eebf04"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "unreachable"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "382810877fe448991dfc7f0dd6e3ae5d58088fd0ea5e35189655f84e6814fa56"
|
|
|
|
dependencies = [
|
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "untrusted"
|
|
|
|
version = "0.7.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a156c684c91ea7d62626509bce3cb4e1d9ed5c4d978f7b4352658f96a4c26b4a"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "url"
|
|
|
|
version = "1.7.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "dd4e7c0d531266369519a4aa4f399d748bd37043b00bde1e4ff1f60a120b355a"
|
|
|
|
dependencies = [
|
|
|
|
"idna 0.1.5",
|
|
|
|
"matches",
|
|
|
|
"percent-encoding 1.0.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "url"
|
|
|
|
version = "2.2.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "a507c383b2d33b5fc35d1861e77e6b383d158b2da5e14fe51b83dfedf6fd578c"
|
|
|
|
dependencies = [
|
|
|
|
"form_urlencoded",
|
|
|
|
"idna 0.2.3",
|
|
|
|
"matches",
|
|
|
|
"percent-encoding 2.1.0",
|
2022-05-23 05:16:04 +03:00
|
|
|
"serde",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "urlencoding"
|
2022-05-26 05:14:11 +03:00
|
|
|
version = "2.1.0"
|
2022-05-23 05:16:04 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-05-26 05:14:11 +03:00
|
|
|
checksum = "68b90931029ab9b034b300b797048cf23723400aa757e8a2bfb9d748102f9821"
|
2022-05-23 05:16:04 +03:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "utf8-width"
|
|
|
|
version = "0.1.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5190c9442dcdaf0ddd50f37420417d219ae5261bbf5db120d0f9bab996c9cba1"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "uuid"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.8.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "bc5cf98d8186244414c848017f0e2676b3fcb46807f6668a97dfe67359a3c4b7"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
"getrandom 0.2.6",
|
2021-01-25 17:41:20 +03:00
|
|
|
"serde",
|
2022-05-26 05:14:11 +03:00
|
|
|
"sha1 0.6.1",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "uuid"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "93bbc61e655a4833cf400d0d15bf3649313422fa7572886ad6dab16d79886365"
|
|
|
|
dependencies = [
|
|
|
|
"getrandom 0.2.6",
|
|
|
|
"serde",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-17 06:13:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "valuable"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "830b7e5d4d90034032940e4ace0d9a9a057e7a45cd94e6c007832e39edb82f6d"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "value-bag"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
version = "1.0.0-alpha.9"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
checksum = "2209b78d1249f7e6f3293657c9779fe31ced465df091bbd433a1cf88e916ec55"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"ctor",
|
2022-02-16 15:58:02 +03:00
|
|
|
"version_check 0.9.4",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "vcpkg"
|
|
|
|
version = "0.2.15"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "accd4ea62f7bb7a82fe23066fb0957d48ef677f6eeb8215f372f52e48bb32426"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "version_check"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "914b1a6776c4c929a602fafd8bc742e06365d4bcbe48c30f9cca5824f70dc9dd"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "version_check"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.9.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "49874b5167b65d7193b8aba1567f5c7d93d001cafc34600cee003eda787e483f"
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "void"
|
|
|
|
version = "1.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6a02e4885ed3bc0f2de90ea6dd45ebcbb66dacffe03547fadbb0eeae2770887d"
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "waker-fn"
|
|
|
|
version = "1.1.0"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "9d5b2c62b4012a3e1eca5a7e077d13b3bf498c4073e33ccd58626607748ceeca"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "walkdir"
|
2021-11-10 16:36:08 +03:00
|
|
|
version = "2.3.2"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2021-11-10 16:36:08 +03:00
|
|
|
checksum = "808cf2735cd4b6866113f648b791c6adc5714537bc222d9347bb203386ffda56"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"same-file",
|
2021-11-10 16:36:08 +03:00
|
|
|
"winapi 0.3.9",
|
2021-01-25 17:41:20 +03:00
|
|
|
"winapi-util",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "want"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1ce8a968cb1cd110d136ff8b819a556d6fb6d919363c61534f6860c7eb172ba0"
|
|
|
|
dependencies = [
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2021-11-10 16:36:08 +03:00
|
|
|
"try-lock",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasi"
|
|
|
|
version = "0.9.0+wasi-snapshot-preview1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cccddf32554fecc6acb585f82a32a72e28b48f8c4c1883ddfeeeaa96f7d8e519"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasi"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
version = "0.10.0+wasi-snapshot-preview1"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Multi-process profiles. (#3395)
See: [#181837344](https://www.pivotaltracker.com/story/show/181837344).
I've separated this PR from some deeper changes I'm making to the profile format, because the changeset was getting too complex. The new APIs and tools in this PR are fully-implemented, except the profile format is too simplistic--it doesn't currently support headers that are needed to determine the relative timings of events from different processes.
- Adds basic support for profile files containing data collected by multiple processes.
- Implements `api_events_to_profile`, a tool for converting backend message logs (#3392) to the `profiler` format so they can be merged with frontend profiles (currently they can be merged with `cat`, but the next PR will introduce a merge tool).
- Introduces `message_beanpoles`, a simple tool that diagrams timing relationships between frontend and backend messages.
### Important Notes
- All TODOs introduced here will be addressed in the next PR that defines the new format.
- Introduced a new crate, `enso_profiler_enso_data`, to be used by profile consumers that need to refer to Enso application datatypes to interpret metadata.
- Introduced a `ProfileBuilder` abstraction for writing the JSON profile format; partially decouples the runtime event log structures from the format definition.
- Introducing the conversion performed for `ProfilerBuilder` uncovered that the `.._with_same_start!` low-level `profiler` APIs don't currently work; they return `Started<_>` profilers, but that is inconsistent with the stricter data model that I introduced when I implemented `profiler_data`; they need to return profilers in a created, unstarted state. Low-level async profilers have not been a priority, but once #3382 merges we'll have a way to render their data, which will be really useful because async profilers capture *why* we're doing things. I'll bring up scheduling this in the next performance meeting.
2022-04-21 17:44:03 +03:00
|
|
|
checksum = "1a143597ca7c7793eff794def352d41792a93c481eb1042423ff7ff72ba2c31f"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasi"
|
|
|
|
version = "0.11.0+wasi-snapshot-preview1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9c8d87e72b64a3b4db28d11ce29237c246188f4f51057d65a7eab63b7987e423"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.78"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "632f73e236b219150ea279196e54e610f5dbafa5d61786303d4da54f84e47fce"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"cfg-if 1.0.0",
|
2021-11-10 16:36:08 +03:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2021-01-25 17:41:20 +03:00
|
|
|
"wasm-bindgen-macro",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-backend"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.78"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "a317bf8f9fba2476b4b2c85ef4c4af8ff39c3c7f0cdfeed4f82c34a880aa837b"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"bumpalo",
|
|
|
|
"lazy_static",
|
Profiling batch mode (#3428)
Implement a command that launches the application, runs a series of steps (a "workflow"), writes a profile to a file, and exits.
See: [#181775808](https://www.pivotaltracker.com/story/show/181775808)
# Important Notes
- The command to capture run and profile is used like: `./run profile --workflow=new_project --save-profile=out.json`. Defining some more workflows (collapse nodes, create node and edit value) comes next; they are implemented with the same infrastructure as the integration-tests.
- The `--save-profile` option can also be used when profiling interactively; when the option is provided, capturing a profile with the hotkey will write a file instead of dumping the data to the devtools console.
- If the IDE panics, the error message is now printed to the console that invoked the process, as well as the devtools console. (If a batch workflow fails, this allows us to see why.)
- New functionality (writing profile files, quitting on command, logging to console) relies on Electron APIs. These APIs are implemented in `index.js`, bridged to the render process in `preload.js`, and wrapped for use in Rust in a `debug_api` crate.
2022-05-10 22:34:40 +03:00
|
|
|
"log 0.4.17",
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-05 18:55:55 +03:00
|
|
|
"syn",
|
2021-01-25 17:41:20 +03:00
|
|
|
"wasm-bindgen-shared",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-futures"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.4.28"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "8e8d7523cb1f2a4c96c1317ca690031b714a51cc14e05f712446691f413f5d39"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
2022-02-16 15:58:02 +03:00
|
|
|
"cfg-if 1.0.0",
|
2021-10-30 16:04:07 +03:00
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-macro"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.78"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "d56146e7c495528bf6587663bea13a8eb588d39b36b679d83972e1a2dbbdacf9"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"quote",
|
2021-01-25 17:41:20 +03:00
|
|
|
"wasm-bindgen-macro-support",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-macro-support"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.78"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "7803e0eea25835f8abdc585cd3021b3deb11543c6fe226dcd30b228857c5c5ab"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-11-05 18:55:55 +03:00
|
|
|
"syn",
|
2021-01-25 17:41:20 +03:00
|
|
|
"wasm-bindgen-backend",
|
|
|
|
"wasm-bindgen-shared",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-shared"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.2.78"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "0237232789cf037d5480773fe568aac745bfe2afbc11a863e97901780a6b47cc"
|
2021-01-25 17:41:20 +03:00
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-test"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.28"
|
2021-11-10 16:36:08 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "96f1aa7971fdf61ef0f353602102dbea75a56e225ed036c1e3740564b91e6b7e"
|
2021-11-10 16:36:08 +03:00
|
|
|
dependencies = [
|
|
|
|
"console_error_panic_hook",
|
2021-10-30 16:04:07 +03:00
|
|
|
"js-sys",
|
|
|
|
"scoped-tls",
|
|
|
|
"wasm-bindgen",
|
2022-02-11 15:19:02 +03:00
|
|
|
"wasm-bindgen-futures",
|
|
|
|
"wasm-bindgen-test-macro",
|
2021-10-30 16:04:07 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-test-macro"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.28"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "6006f79628dfeb96a86d4db51fbf1344cd7fd8408f06fc9aa3c84913a4789688"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
2022-02-11 15:19:02 +03:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
2021-10-30 16:04:07 +03:00
|
|
|
[[package]]
|
|
|
|
name = "weak-table"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.2"
|
2021-10-30 16:04:07 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "323f4da9523e9a669e1eaf9c6e763892769b1d38c623913647bfdc1532fe4549"
|
2021-10-30 16:04:07 +03:00
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "web-sys"
|
2022-02-16 15:58:02 +03:00
|
|
|
version = "0.3.55"
|
2021-01-25 17:41:20 +03:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-02-16 15:58:02 +03:00
|
|
|
checksum = "38eb105f1c59d9eaa6b5cdc92b859d85b926e82cb2e0945cd0c9259faa6fe9fb"
|
2021-01-25 17:41:20 +03:00
|
|
|
dependencies = [
|
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "webpki"
|
|
|
|
version = "0.21.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b8e38c0608262c46d4a56202ebabdeb094cef7e560ca7a226c6bf055188aa4ea"
|
|
|
|
dependencies = [
|
|
|
|
"ring",
|
|
|
|
"untrusted",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "webpki"
|
|
|
|
version = "0.22.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f095d78192e208183081cc07bc5515ef55216397af48b873e5edcd72637fa1bd"
|
|
|
|
dependencies = [
|
|
|
|
"ring",
|
|
|
|
"untrusted",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "webpki-roots"
|
|
|
|
version = "0.22.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "44d8de8415c823c8abd270ad483c6feeac771fad964890779f9a8cb24fbbc1bf"
|
|
|
|
dependencies = [
|
|
|
|
"webpki 0.22.0",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "websocket"
|
|
|
|
version = "0.23.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b255b190f412e45000c35be7fe9b48b39a2ac5eb90d093d421694e5dae8b335c"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.10.1",
|
|
|
|
"bitflags",
|
|
|
|
"byteorder",
|
|
|
|
"bytes 0.4.12",
|
|
|
|
"futures 0.1.31",
|
|
|
|
"hyper 0.10.16",
|
|
|
|
"native-tls",
|
|
|
|
"rand 0.6.5",
|
2022-05-26 05:14:11 +03:00
|
|
|
"sha1 0.6.1",
|
2021-11-10 16:36:08 +03:00
|
|
|
"tokio-codec",
|
|
|
|
"tokio-io",
|
|
|
|
"tokio-reactor",
|
|
|
|
"tokio-tcp",
|
|
|
|
"tokio-tls 0.2.1",
|
|
|
|
"unicase 1.4.2",
|
|
|
|
"url 1.7.2",
|
|
|
|
]
|
|
|
|
|
2021-11-30 18:23:46 +03:00
|
|
|
[[package]]
|
|
|
|
name = "welcome-screen"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"enso-frp",
|
|
|
|
"ensogl",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2022-02-16 15:58:02 +03:00
|
|
|
[[package]]
|
|
|
|
name = "wepoll-ffi"
|
|
|
|
version = "0.1.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d743fdedc5c64377b5fc2bc036b01c7fd642205a0d96356034ae3404d49eb7fb"
|
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "which"
|
|
|
|
version = "4.2.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5c4fb54e6113b6a8772ee41c3404fb0301ac79604489467e0a9ce1f3e97c24ae"
|
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
"lazy_static",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "whoami"
|
|
|
|
version = "1.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "524b58fa5a20a2fb3014dd6358b70e6579692a56ef6fce928834e488f42f65e8"
|
|
|
|
dependencies = [
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "winapi"
|
|
|
|
version = "0.2.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "167dc9d6949a9b857f3451275e911c3f44255842c1f7a76f33c55103a909087a"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "winapi"
|
|
|
|
version = "0.3.9"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5c839a674fcd7a98952e593242ea400abe93992746761e38641405d28b00f419"
|
|
|
|
dependencies = [
|
|
|
|
"winapi-i686-pc-windows-gnu",
|
|
|
|
"winapi-x86_64-pc-windows-gnu",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "winapi-build"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2d315eee3b34aca4797b2da6b13ed88266e6d612562a0c46390af8299fc699bc"
|
|
|
|
|
2021-01-25 17:41:20 +03:00
|
|
|
[[package]]
|
|
|
|
name = "winapi-i686-pc-windows-gnu"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "winapi-util"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "70ec6ce85bb158151cae5e5c87f95a8e97d2c0c4b001223f33a334e3ce5de178"
|
|
|
|
dependencies = [
|
2021-11-10 16:36:08 +03:00
|
|
|
"winapi 0.3.9",
|
2021-01-25 17:41:20 +03:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "winapi-x86_64-pc-windows-gnu"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f"
|
2021-11-10 16:36:08 +03:00
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "windows-sys"
|
|
|
|
version = "0.36.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ea04155a16a59f9eab786fe12a4a450e75cdb175f9e0d80da1e17db09f55b8d2"
|
|
|
|
dependencies = [
|
|
|
|
"windows_aarch64_msvc",
|
|
|
|
"windows_i686_gnu",
|
|
|
|
"windows_i686_msvc",
|
|
|
|
"windows_x86_64_gnu",
|
|
|
|
"windows_x86_64_msvc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows_aarch64_msvc"
|
|
|
|
version = "0.36.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9bb8c3fd39ade2d67e9874ac4f3db21f0d710bee00fe7cab16949ec184eeaa47"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows_i686_gnu"
|
|
|
|
version = "0.36.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "180e6ccf01daf4c426b846dfc66db1fc518f074baa793aa7d9b9aaeffad6a3b6"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows_i686_msvc"
|
|
|
|
version = "0.36.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e2e7917148b2812d1eeafaeb22a97e4813dfa60a3f8f78ebe204bcc88f12f024"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_gnu"
|
|
|
|
version = "0.36.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4dcd171b8776c41b97521e5da127a2d86ad280114807d0b2ab1e462bc764d9e1"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_msvc"
|
|
|
|
version = "0.36.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c811ca4a8c853ef420abd8592ba53ddbbac90410fab6903b3e79972a631f7680"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "winreg"
|
|
|
|
version = "0.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0120db82e8a1e0b9fb3345a539c478767c0048d842860994d96113d5b667bd69"
|
|
|
|
dependencies = [
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "winreg"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "80d0f4e272c85def139476380b12f9ac60926689dd2e01d4923222f40580869d"
|
|
|
|
dependencies = [
|
|
|
|
"winapi 0.3.9",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wiremock"
|
|
|
|
version = "0.5.13"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1b12f508bdca434a55d43614d26f02e6b3e98ebeecfbc5a1614e0a0c8bf3e315"
|
|
|
|
dependencies = [
|
|
|
|
"assert-json-diff",
|
|
|
|
"async-trait",
|
|
|
|
"deadpool",
|
|
|
|
"futures 0.3.21",
|
|
|
|
"futures-timer",
|
|
|
|
"http-types",
|
|
|
|
"hyper 0.14.18",
|
|
|
|
"log 0.4.17",
|
|
|
|
"once_cell",
|
|
|
|
"regex",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
Better `release` build time; new maximum-performance `production` profile. (#3498)
### Pull Request Description
Using the new tooling (#3491), I investigated the **performance / compile-time tradeoff** of different codegen options for release mode builds. By scripting the testing procedure, I was able to explore many possible combinations of options, which is important because their interactions (on both application performance and build time) are complex. I found **two candidate profiles** that offer specific advantages over the current `release` settings (`baseline`):
- `thin16`: Supports incremental compiles in 1/3 the time of `baseline` in common cases. Application runs about 2% slower than `baseline`.
- `fat1-O4`: Application performs 13% better than `baseline`. Compile time is almost 3x `baseline`, and non-incremental.
(See key in first chart for the settings defining these profiles.)
We can build faster or run faster, though not in the same build. Because the effect sizes are large enough to be impactful to developer and user experience, respectively, I think we should consider having it both ways. We could **split the `release` profile** into two profiles to serve different purposes:
- `release`: A profile that supports fast developer iteration, while offering realistic performance.
- `production`: A maximally-optimized profile, for nightly builds and actual releases.
Since `wasm-pack` doesn't currently support custom profiles (rustwasm/wasm-pack#1111), we can't use a Cargo profile for `production`; however, we can implement our own profile by overriding rustc flags.
### Performance details
![perf](https://user-images.githubusercontent.com/1047859/170788530-ab6d7910-5253-4a2b-b432-8bfa0b4735ba.png)
As you can see, `thin16` is slightly slower than `baseline`; `fat1-O4` is dramatically faster.
<details>
<summary>Methodology (click to show)</summary>
I developed a procedure for benchmarking "whole application" performance, using the new "open project" workflow (which opens the IDE and loads a complex project), and some statistical analysis to account for variance. To gather this data:
Build the application with profiling:
`./run.sh ide build --profiling-level=debug`
Run the `open_project` workflow repeatedly:
`for i in $(seq 0 9); do dist/ide/linux-unpacked/enso --entry-point profile --workflow open_project --save-profile open_project_thin16_${i}.json; done`
For each profile recorded, take the new `total_self_time` output of the `intervals` tool; gather into CSV:
`echo $(for i in $(seq 0 9); do target/rust/debug/intervals < open_project_thin16_${i}.json | tail -n1 | awk '{print $2}'; do`
(Note that the output of intervals should not be considered stable; this command may need modification in the future. Eventually it would be nice to support formatted outputs...)
The data is ready to graph. I used the `boxplot` method of the [seaborn](https://seaborn.pydata.org/index.html) package, in order to show the distribution of data.
</details>
#### Build times
![thin16](https://user-images.githubusercontent.com/1047859/170788539-1578e41b-bc30-4f30-9b71-0b0181322fa5.png)
In the case of changing a file in `enso-prelude`, with the current `baseline` settings rebuilding takes over 3 minutes. With the `thin16` settings, the same rebuild completes in 40 seconds.
(To gather this data on different hardware or in the future, just run the new `bench-build.sh` script for each case to be measured.)
2022-06-11 01:09:54 +03:00
|
|
|
"tokio 1.19.2",
|
2022-05-23 05:16:04 +03:00
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "ws2_32-sys"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d59cefebd0c892fa2dd6de581e937301d8552cb44489cdff035c6187cb63fa5e"
|
|
|
|
dependencies = [
|
|
|
|
"winapi 0.2.8",
|
|
|
|
"winapi-build",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "xattr"
|
|
|
|
version = "0.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6d1526bbe5aaeb5eb06885f4d987bcdfa5e23187055de9b83fe00156a821fabc"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "xi-rope"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c1266c6612194a86462905372bc7bbc9887e3f3826da6b82ea4a35492bc65d5a"
|
|
|
|
dependencies = [
|
|
|
|
"bytecount",
|
|
|
|
"memchr",
|
|
|
|
"regex",
|
|
|
|
"unicode-segmentation",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "xmlparser"
|
|
|
|
version = "0.13.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "114ba2b24d2167ef6d67d7d04c8cc86522b87f490025f39f0303b7db5bf5e3d8"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "yaml-rust"
|
|
|
|
version = "0.4.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "56c1936c4cc7a1c9ab21a1ebb602eb942ba868cbd44a99cb7cdc5892335e1c85"
|
|
|
|
dependencies = [
|
|
|
|
"linked-hash-map",
|
|
|
|
]
|
|
|
|
|
2022-05-23 05:16:04 +03:00
|
|
|
[[package]]
|
|
|
|
name = "zeroize"
|
|
|
|
version = "1.5.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "94693807d016b2f2d2e14420eb3bfcca689311ff775dcf113d74ea624b7cdf07"
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "zip"
|
|
|
|
version = "0.5.13"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "93ab48844d61251bb3835145c521d88aa4031d7139e8485990f60ca911fa0815"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
"bzip2",
|
|
|
|
"crc32fast",
|
|
|
|
"flate2",
|
|
|
|
"thiserror",
|
2022-05-23 05:16:04 +03:00
|
|
|
"time 0.1.44",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|
|
|
|
|
2022-05-26 05:14:11 +03:00
|
|
|
[[package]]
|
|
|
|
name = "zip"
|
|
|
|
version = "0.6.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bf225bcf73bb52cbb496e70475c7bd7a3f769df699c0020f6c7bd9a96dcf0b8d"
|
|
|
|
dependencies = [
|
|
|
|
"aes",
|
|
|
|
"byteorder",
|
|
|
|
"bzip2",
|
|
|
|
"constant_time_eq",
|
|
|
|
"crc32fast",
|
|
|
|
"crossbeam-utils 0.8.8",
|
|
|
|
"flate2",
|
|
|
|
"hmac",
|
|
|
|
"pbkdf2",
|
|
|
|
"sha1 0.10.1",
|
|
|
|
"time 0.3.9",
|
|
|
|
"zstd",
|
|
|
|
]
|
|
|
|
|
2021-11-10 16:36:08 +03:00
|
|
|
[[package]]
|
|
|
|
name = "zip-extensions"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9adcf027b355870f62cabaed021f9028231d2d84cad6e30a7abdaa4dc0390edd"
|
|
|
|
dependencies = [
|
2022-05-26 05:14:11 +03:00
|
|
|
"zip 0.5.13",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zstd"
|
|
|
|
version = "0.10.2+zstd.1.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5f4a6bd64f22b5e3e94b4e238669ff9f10815c27a5180108b849d24174a83847"
|
|
|
|
dependencies = [
|
|
|
|
"zstd-safe",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zstd-safe"
|
|
|
|
version = "4.1.6+zstd.1.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "94b61c51bb270702d6167b8ce67340d2754b088d0c091b06e593aa772c3ee9bb"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"zstd-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zstd-sys"
|
|
|
|
version = "1.6.3+zstd.1.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fc49afa5c8d634e75761feda8c592051e7eeb4683ba827211eb0d731d3402ea8"
|
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"libc",
|
2021-11-10 16:36:08 +03:00
|
|
|
]
|