enso/Cargo.lock

7905 lines
176 KiB
Plaintext
Raw Normal View History

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"
version = "0.17.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b9ecd88a8c8378ca913a680cd98f0f13ac67383d35993f86c90a70e3f137816b"
2021-01-25 17:41:20 +03:00
dependencies = [
"gimli",
]
[[package]]
name = "adler"
version = "1.0.2"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f26201604c87b1e01bd3d98f8d5d9a8fcbb815e8cedb41ffccbeb4bf593a35fe"
2021-01-25 17:41:20 +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"
version = "0.7.18"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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"
[[package]]
name = "analytics"
version = "0.1.0"
dependencies = [
"js-sys",
"wasm-bindgen",
]
[[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"
version = "1.0.57"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
]
[[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",
]
[[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"
dependencies = [
"ast-macros",
"derive_more",
"enso-data-structures",
"enso-prelude",
"enso-profiler",
"enso-shapely",
"enso-text",
"failure",
"lazy_static",
"regex",
"serde",
"serde_json",
"shrinkwraprs 0.2.3",
"uuid 0.8.2",
]
[[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",
"syn",
]
[[package]]
name = "async-channel"
version = "1.6.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
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
]
[[package]]
name = "async-executor"
version = "1.4.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "871f9bb5e0a22eeb7e8cf16641feb87c9dc67032ccf8ff49e772eb9941d3a965"
dependencies = [
"async-task",
"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"
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"
dependencies = [
"async-channel",
"async-executor",
"async-io",
"async-mutex",
"blocking",
"futures-lite",
"num_cpus",
"once_cell",
]
[[package]]
name = "async-io"
version = "1.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e5e18f61464ae81cde0a23e713ae8fd299580c54d697a35820cfd0625b8b0e07"
dependencies = [
"concurrent-queue",
"futures-lite",
"libc",
"log 0.4.17",
"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"
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"
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"
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"
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",
"futures-channel",
"futures-core",
"futures-io",
"futures-lite",
"gloo-timers",
"kv-log-macro",
"log 0.4.17",
"memchr",
"num_cpus",
"once_cell",
"pin-project-lite 0.2.9",
"pin-utils",
"slab",
"wasm-bindgen-futures",
]
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",
]
[[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"
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-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",
]
[[package]]
name = "async_once"
version = "0.2.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2ce4f10ea3abcd6617873bae9f91d1c5332b4a778bd9ce34d0cd517474c1de82"
[[package]]
name = "atomic-waker"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "065374052e7df7ee4047b1160cca5e1467a12351a40b3da123c870ba0b8eda2a"
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",
"winapi 0.3.9",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "autocfg"
version = "0.1.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0dde43e75fd43e8a1bf86103336bc699aa8d17ad1be60c76c0bdfd4828e19b78"
dependencies = [
"autocfg 1.1.0",
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "autocfg"
version = "1.1.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d468802bab17cbc0cc575e9b053f41e72aa36bfa6b7f55e3529ffa43161b97fa"
2021-01-25 17:41:20 +03:00
2022-05-23 05:16:04 +03:00
[[package]]
name = "aws-config"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c2a3ad9e793335d75b2d2faad583487efcc0df9154aff06f299a5c1fc8795698"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-http",
"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",
"hex",
2022-05-23 05:16:04 +03:00
"http",
"hyper 0.14.18",
"ring",
"time 0.3.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",
"zeroize",
2022-05-23 05:16:04 +03:00
]
[[package]]
name = "aws-endpoint"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8bd4e9dad553017821ee529f186e033700e8d61dd5c4b60066b4d8fe805b8cfc"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-smithy-http",
"aws-types",
"http",
"regex",
"tracing",
]
[[package]]
name = "aws-http"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2ef5a579a51d352b628b76f4855ba716be686305e5e59970c476d1ae2214e90d"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-smithy-http",
"aws-smithy-types",
"aws-types",
"bytes 1.1.0",
2022-05-23 05:16:04 +03:00
"http",
"http-body 0.4.5",
2022-05-23 05:16:04 +03:00
"lazy_static",
"percent-encoding 2.1.0",
"pin-project-lite 0.2.9",
2022-05-23 05:16:04 +03:00
"tracing",
]
[[package]]
name = "aws-sdk-ecr"
version = "0.17.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "84bf0237b7c85f440ba6e19d23696751200d33c0b481a246eb7df869aa231cea"
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-s3"
version = "0.17.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0d2c19b69297f16b3f18936e363f954e7504c23a4a0dc3f2833712313c09c2aa"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-endpoint",
"aws-http",
"aws-sig-auth",
"aws-sigv4",
"aws-smithy-async",
"aws-smithy-checksums",
2022-05-23 05:16:04 +03:00
"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",
"bytes-utils",
2022-05-23 05:16:04 +03:00
"http",
"http-body 0.4.5",
2022-05-23 05:16:04 +03:00
"tokio-stream",
"tower",
"tracing",
2022-05-23 05:16:04 +03:00
]
[[package]]
name = "aws-sdk-sso"
version = "0.17.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f014b8ad3178b414bf732b36741325ef659fc40752f8c292400fb7c4ecb7fdd0"
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"
version = "0.17.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d37e45fdce84327c69fb924b9188fd889056c6afafbd494e8dd0daa400f9c082"
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"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6530e72945c11439e9b3c423c95a656a233d73c3a7d4acaf9789048e1bdf7da7"
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"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6351c3ba468b04bd819f64ea53538f5f53e3d6b366b27deabee41e73c9edb3af"
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"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "86fc23ad8d050c241bdbfa74ae360be94a844ace8e218f64a2b2de77bfa9a707"
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-checksums"
version = "0.47.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6dd674df030b337a84eb67539db048676c691d9c88f0c54cf7748da11836cfd8"
dependencies = [
"aws-smithy-http",
"aws-smithy-types",
"bytes 1.1.0",
"crc32c",
"crc32fast",
"hex",
"http",
"http-body 0.4.5",
"md-5",
"pin-project-lite 0.2.9",
"sha1 0.10.1",
"sha2",
"tracing",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "aws-smithy-client"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2e147b157f49ce77f2a86ec693a14c84b2441fa28be58ffb2febb77d5726c934"
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-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"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "da29e67a0b90a2bc5f2bd0a06fd43e728de62e02048879c15f646a3edf8db012"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-smithy-types",
"bytes 1.1.0",
"crc32fast",
]
[[package]]
name = "aws-smithy-http"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5cc1af50eac644ab6f58e5bae29328ba3092851fc2ce648ad139134699b2b66f"
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",
"once_cell",
2022-05-23 05:16:04 +03:00
"percent-encoding 2.1.0",
"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",
"tokio-util 0.7.2",
2022-05-23 05:16:04 +03:00
"tracing",
]
[[package]]
name = "aws-smithy-http-tower"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a1bf4c4664dff2febf91f8796505c5bc8f38a0bff0d1397d1d3fdda17bd5c5d1"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-smithy-http",
"bytes 1.1.0",
"http",
"http-body 0.4.5",
"pin-project-lite 0.2.9",
2022-05-23 05:16:04 +03:00
"tower",
"tracing",
]
[[package]]
name = "aws-smithy-json"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0e6ebc76c3c108dd2a96506bf47dc31f75420811a19f1a09907524d1451789d2"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-smithy-types",
]
[[package]]
name = "aws-smithy-query"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2956f1385c4daa883907a2c81d32256af8f95834c9de1bc0613fa68db63b88c4"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-smithy-types",
"urlencoding",
]
[[package]]
name = "aws-smithy-types"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "352fb335ec1d57160a17a13e87aaa0a172ab780ddf58bfc85caedd3b7e47caed"
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"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6cf2807fa715a5a3296feffb06ce45252bd0dfd48f52838128c48fb339ddbf5c"
2022-05-23 05:16:04 +03:00
dependencies = [
"xmlparser",
]
[[package]]
name = "aws-types"
version = "0.47.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8140b89d76f67be2c136d7393e7e6d8edd65424eb58214839efbf4a2e4f7e8a3"
2022-05-23 05:16:04 +03:00
dependencies = [
"aws-smithy-async",
"aws-smithy-client",
"aws-smithy-http",
2022-05-23 05:16:04 +03:00
"aws-smithy-types",
"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",
"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",
]
[[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",
]
[[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"
[[package]]
name = "base64ct"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8a32fd6af2b5827bce66c29053ba0e7c42b9dcab01835835058558c10851a46b"
[[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",
]
2022-08-27 01:25:34 +03:00
[[package]]
name = "bincode"
version = "2.0.0-rc.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f609ceb2c41b0d0277314a789ef0e7eb14593d5485f7c67320bed3924ebb1b33"
dependencies = [
"bincode_derive",
]
[[package]]
name = "bincode_derive"
version = "2.0.0-rc.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "913287a8f3e00db4c7ae1b87e9b9b8cebd6b89217eaadfc281fa5c897da35dc3"
dependencies = [
"virtue",
]
[[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"
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",
]
[[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"
checksum = "fa79dedbb091f449f1f39e53edf88d5dbe95f895dae6135a8d7b881fb5af73f5"
dependencies = [
"byte-tools",
]
2021-01-25 17:41:20 +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"
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"
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"
version = "0.2.17"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ba3569f383e8f1598449f1a423e72e99569137b47740b1da11ef19af3d5c3223"
2021-01-25 17:41:20 +03:00
dependencies = [
"lazy_static",
"memchr",
"regex-automata",
"serde",
]
[[package]]
name = "build-scripts"
version = "0.1.0"
dependencies = [
"glob",
"toml",
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "bumpalo"
version = "3.9.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a4a45a46ab1f2412e53d3a0ade76ffad2025804294569aae387231a0cd6e0899"
[[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",
]
[[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"
checksum = "be0fdd54b507df8f22012890aadd099979befdba27713c767993f8380112ca7c"
2021-01-25 17:41:20 +03:00
[[package]]
name = "byteorder"
version = "1.4.3"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "14c189c53d098945499cdfa7ecc63567cf3886b3332b312a5b4585d8d3a6a610"
2021-01-25 17:41:20 +03:00
[[package]]
name = "bytes"
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",
]
[[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"
checksum = "736a955f3fa7875102d57c82b8cac37ec45224a07fd32d58f9f7a186b6cd4cdc"
dependencies = [
"cc",
"libc",
"pkg-config",
]
2021-01-25 17:41:20 +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"
version = "0.34.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "aadf76ddea74bab35ebeb8f1eb115b9bc04eaee42d8acc0d5f477dee6b176c9a"
2022-05-23 05:16:04 +03:00
dependencies = [
"async-trait",
"async_once",
"cached_proc_macro 0.12.0",
"cached_proc_macro_types",
"futures 0.3.21",
"hashbrown",
"lazy_static",
"once_cell",
"thiserror",
"tokio 1.19.2",
]
[[package]]
name = "cached"
version = "0.38.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "27e6092f8c7ba6e65a46f6f26d7d7997201d3a6f0e69ff5d2440b930d7c0513a"
dependencies = [
"async-trait",
"async_once",
"cached_proc_macro 0.15.0",
2022-05-23 05:16:04 +03:00
"cached_proc_macro_types",
"futures 0.3.21",
"hashbrown",
"instant",
"lazy_static",
2022-05-23 05:16:04 +03:00
"once_cell",
"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"
version = "0.12.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bce0f37f9b77c6b93cdf3f060c89adca303d2ab052cacb3c3d1ab543e8cecd2f"
2022-05-23 05:16:04 +03:00
dependencies = [
"cached_proc_macro_types",
"darling",
"quote",
"syn",
]
[[package]]
name = "cached_proc_macro"
version = "0.15.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "751f7f4e7a091545e7f6c65bacc404eaee7e87bfb1f9ece234a1caa173dc16f2"
dependencies = [
"cached_proc_macro_types",
"darling",
"quote",
"syn",
]
2022-05-23 05:16:04 +03:00
[[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"
version = "0.2.7"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4c24dab4283a142afa2fdca129b80ad2c6284e073930f964c3a1293c225ee39a"
2021-01-25 17:41:20 +03:00
dependencies = [
"rustc_version 0.4.0",
2021-01-25 17:41:20 +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"
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"
dependencies = [
"jobserver",
]
[[package]]
name = "cesu8"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6d43a04d8753f35258c91f8ec639f792891f748a1edbd759cf1dcea3382ad83c"
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"
[[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",
"winapi 0.3.9",
]
[[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"
version = "2.34.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
]
[[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 = "combine"
version = "4.6.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2a604e93b79d1808327a6fca85a6f2d69de66461e7620f5a4cbf5fb4d1d7c948"
dependencies = [
"bytes 1.1.0",
"memchr",
]
2022-05-23 05:16:04 +03:00
[[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 0.8.24",
2022-05-23 05:16:04 +03:00
]
[[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",
"winapi 0.3.9",
2021-10-30 16:04:07 +03:00
]
[[package]]
2022-05-23 05:16:04 +03:00
name = "console-api"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "06c5fd425783d81668ed68ec98408a80498fb4ae2fd607797539e1a9dfa3618f"
dependencies = [
2022-05-23 05:16:04 +03:00
"prost",
"prost-types",
"tonic",
"tracing-core",
]
[[package]]
2022-05-23 05:16:04 +03:00
name = "console-subscriber"
version = "0.1.6"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "31432bc31ff8883bf6a693a79371862f73087822470c82d6a1ec778781ee3978"
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",
"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-10-30 16:04:07 +03:00
[[package]]
name = "console_error_panic_hook"
version = "0.1.7"
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",
]
[[package]]
name = "const_format"
version = "0.2.23"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0936ffe6d0c8d6a51b3b0a73b2acbe925d786f346cf45bfddc8341d79fb7dc8a"
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",
]
[[package]]
name = "constant_time_eq"
version = "0.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "245097e9a4535ee1e3e3931fcfcd55a796a44c643e8596ff6566d68f09b87bbc"
[[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"
[[package]]
name = "core-foundation"
version = "0.9.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "194a7a9e6de53fa55116934067c844d9d749312f75c6f6d0980e8c252f8c2146"
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"
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",
]
[[package]]
name = "crc32c"
version = "0.6.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3dfea2db42e9927a3845fb268a10a72faed6d416065f77873f05e411457c363e"
dependencies = [
"rustc_version 0.4.0",
]
2021-05-14 15:08:39 +03:00
[[package]]
name = "crc32fast"
version = "1.3.2"
2021-05-14 15:08:39 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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"
version = "0.3.5"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
"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"
version = "0.4.4"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d00996de9f2f7559f7f4dc286073197f83e92256a59ed395f9aac01fe717da57"
2021-01-25 17:41:20 +03:00
dependencies = [
"cast",
"itertools 0.10.3",
2021-01-25 17:41:20 +03:00
]
2022-07-01 04:58:14 +03:00
[[package]]
name = "cron"
version = "0.11.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d76219e9243e100d5a37676005f08379297f8addfebc247613299600625c734d"
dependencies = [
"chrono",
"nom",
"once_cell",
]
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"
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",
]
[[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"
checksum = "6455c0ca19f0d2fbf751b908d5c55c1f5cbc65e03c4225427254b46890bdde1e"
2021-01-25 17:41:20 +03:00
dependencies = [
"cfg-if 1.0.0",
"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",
]
[[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"
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",
"memoffset",
2021-01-25 17:41:20 +03:00
"scopeguard",
]
[[package]]
name = "crossbeam-utils"
version = "0.7.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c3c7c73a2d1e9fc0886a08b93e98eb643461230d5f1925e4036204d5f2e261a8"
dependencies = [
"autocfg 1.1.0",
"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"
version = "1.1.6"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "22813a6dc45b335f9bade10bf7271dc477e81113e89eb251a0bc2a8a81c536e1"
2021-01-25 17:41:20 +03:00
dependencies = [
"bstr",
"csv-core",
"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",
]
[[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"
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"
dependencies = [
2022-02-11 15:19:02 +03:00
"quote",
"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"
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
[[package]]
name = "debug-scene-component-group"
version = "0.1.0"
dependencies = [
"enso-frp",
"enso-text",
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-list-view",
Fully visible group name in partially scrolled Component Group View (#3447) [ci no changelog needed] [Task link](https://www.pivotaltracker.com/story/show/181725003) This PR implements a fully visible component group header while scrolling the group (using the ScrollArea). The header moves in sync with scrolling movements (using new `set_header_pos` FRP input), so it looks like the component group is scrolled. ScrollArea masks the "scrolled" entries above the header. This design allows a fully visible header even though our renderer doesn't support nested layers masking yet. The screencast: https://user-images.githubusercontent.com/6566674/168320360-2c2017b2-0ef5-42ce-9c79-82b9641c1d73.mp4 The most recent one, with the updated demo scene from develop: https://user-images.githubusercontent.com/6566674/168555268-8552c4b0-f887-4388-89a1-e65ddf668be6.mp4 # Important Notes - I fixed the API of the list view so now it supports non-hardcoded scene layers (previously it did not). I also believe it was implemented incorrectly. - I've found a [pretty weird bug](https://www.pivotaltracker.com/story/show/182193824): the component group inside the ScrollArea is invisible unless I add some arbitrary shape to the scroll area content. I use a `transparent_circle` for this purpose in the demo scene. The bug is probably related to masking the sublayers, though I wasn't able to reproduce it properly on a simpler example. - The selection box is removed from the demo scene as agreed with @farmaazon . The correct implementation has proven to be much harder than I expected, and we will implement another approach in a separate PR. - I also modified the `shadow::Parameters` so that it uses `Var`s instead of plain values.
2022-05-17 16:52:08 +03:00
"ensogl-scroll-area",
"ensogl-selector",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
"ide-view-component-group",
"wasm-bindgen",
]
2022-06-22 18:39:32 +03:00
[[package]]
name = "debug-scene-component-list-panel-view"
version = "0.1.0"
dependencies = [
"enso-frp",
"enso-profiler",
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-list-view",
"ensogl-selector",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
2022-06-22 18:39:32 +03:00
"ide-view-component-group",
"ide-view-component-list-panel",
"js-sys",
2022-06-22 18:39:32 +03:00
"wasm-bindgen",
]
[[package]]
name = "debug-scene-icons"
version = "0.1.0"
dependencies = [
"ensogl",
"ensogl-hardcoded-theme",
"ide-view-component-group",
"wasm-bindgen",
]
[[package]]
name = "debug-scene-interface"
version = "0.1.0"
dependencies = [
"ast",
"enso-frp",
"ensogl",
"ensogl-hardcoded-theme",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"ide-view",
"parser",
"span-tree",
"uuid 0.8.2",
"wasm-bindgen",
]
[[package]]
name = "debug-scene-visualization"
version = "0.1.0"
dependencies = [
"enso-frp",
"ensogl",
"ensogl-hardcoded-theme",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"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",
"syn",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "derive_more"
version = "0.99.17"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
"rustc_version 0.4.0",
"syn",
2021-01-25 17:41:20 +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",
"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"
[[package]]
name = "double-representation"
version = "0.1.0"
dependencies = [
"ast",
Virtual Entries in Component Browser (#3621) Add "text input" and "number input" virtual entries in the "Input" virtual component group in the Component Browser. The entries provide an easy way to put strings and numbers into a graph. https://www.pivotaltracker.com/story/show/181870589 #### Visuals See below for a video showing the "text input" and "number input" virtual entries in the "Input" component group in the "Favorites Data Science Tools" section of the Component Browser. Please note that the video also displays a few known issues that are present in the existing code and not introduced by this PR: - "Opening the Component Browser 2nd or later time flashes its last contents from the previous time" - reported as [issue 15 in PR 3530](https://github.com/enso-org/enso/pull/3530#pullrequestreview-1035698205) (which is [expected](https://github.com/enso-org/enso/pull/3530#issuecomment-1187676313) to be fixed by https://www.pivotaltracker.com/story/show/182610422). - The text of all the entries in the Component Browser does not show immediately, but the entries appear one by one instead (this is related to the performance of the current implementation of Component Browser and Text Area). - Selection in the Component Browser can show half-way between entries - reported as https://www.pivotaltracker.com/story/show/182713338. https://user-images.githubusercontent.com/273837/183472391-c14eeded-481f-492e-a1b8-b86f42faf0cd.mov # Important Notes - The virtual entries are not filtered by input type or return type. The filtering is expected to be implemented in https://www.pivotaltracker.com/story/show/182842444.
2022-08-17 16:28:07 +03:00
"const_format",
"engine-protocol",
"enso-data-structures",
"enso-logger",
"enso-prelude",
Profiling workflows (#3475) Define some workflows for batch-mode profiling. Implemented: - collapse nodes - create node - enter collapsed node - new project - open visualization They can currently be built and run with a command like: `./run.sh ide build --profiling-level=debug && dist/ide/linux-unpacked/enso --entry-point profile --workflow create_node --save-profile out.json` And the data can be displayed with: `dist/ide/linux-unpacked/enso --entry-point profiling_run_graph --load-profile out.json` Demo of recording and viewing a profile with a command-line one-liner: https://user-images.githubusercontent.com/1047859/169954795-2d9520ca-84f9-45d2-b83a-5063ebe6f718.mp4 See: https://www.pivotaltracker.com/story/show/182195399. # Important Notes - When defining workflows, two helpers are enough to allow us to tell when the action is really done: `Fixture::compile_new_shaders`, and `Fixture::backend_execution`. Often, it is appropriate to await both, but it depends on the task. - The shader compiler is now driven by a `Controller`; while the `Compiler` is reset if context is lost, the `Controller`'s state survives context loss. - A new `--load-profile` option supports specifying a profile by path when running `profiling_run_graph`. - Drop the `with_same_start` profiler interface; we ended up preferring a child profiler convention, and this interface was not implemented compatibly with the stricter data model we've had since the introduction of `profiler::data`. - Fix the noisy `rustfmt` output.
2022-06-01 21:01:16 +03:00
"enso-profiler",
"enso-text",
"failure",
"itertools 0.10.3",
"parser",
"regex",
"serde",
"uuid 0.8.2",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
]
[[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.7.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3f107b87b6afc2a64fd13cac55fe06d6c8859f12d4b14cbcdd2c67d0976781be"
2021-01-25 17:41:20 +03:00
[[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]]
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"
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 = [
"cfg-if 1.0.0",
2021-10-30 16:04:07 +03:00
]
[[package]]
name = "engine-protocol"
version = "0.1.0"
2021-10-30 16:04:07 +03:00
dependencies = [
"bytes 0.5.6",
"chrono",
"enso-build-utilities",
"enso-data-structures",
"enso-logger",
"enso-prelude",
"enso-shapely",
"enso-text",
"enso-web",
"failure",
"flatbuffers",
"flatc-rust",
"futures 0.3.21",
"hex",
"json-rpc",
"mockall",
2022-05-23 05:16:04 +03:00
"reqwest 0.10.10",
"serde",
"serde_json",
"sha3",
"strum",
"strum_macros",
2022-05-23 05:16:04 +03:00
"tokio 0.2.25",
"uuid 0.8.2",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
"zip 0.5.13",
"zip-extensions",
]
[[package]]
name = "enso-automata"
version = "0.2.0"
dependencies = [
"enso-prelude",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "enso-build"
version = "0.1.0"
source = "git+https://github.com/enso-org/ci-build?branch=develop#93d7afc1af0ad528444157943c24f9abb5d0b955"
2022-05-23 05:16:04 +03:00
dependencies = [
"anyhow",
"async-compression",
"async-trait",
"aws-config",
"aws-sdk-ecr",
2022-05-23 05:16:04 +03:00
"aws-sdk-s3",
"base64 0.13.0",
2022-05-23 05:16:04 +03:00
"byte-unit",
"bytes 1.1.0",
"cached 0.38.0",
2022-05-23 05:16:04 +03:00
"cfg-if 1.0.0",
"chrono",
"clap 3.1.18",
"console-subscriber",
"derivative",
"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",
"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 0.9.10",
2022-05-23 05:16:04 +03:00
"shrinkwraprs 0.3.0",
"snafu",
"strum",
"sysinfo 0.25.3",
2022-05-23 05:16:04 +03:00
"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",
"uuid 1.1.2",
2022-05-23 05:16:04 +03:00
"walkdir",
"which",
"whoami",
"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"
source = "git+https://github.com/enso-org/ci-build?branch=develop#93d7afc1af0ad528444157943c24f9abb5d0b955"
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",
2022-07-01 04:58:14 +03:00
"chrono",
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
"clap 3.1.18",
"derivative",
"enso-build",
"futures 0.3.21",
"futures-util",
"humantime 2.1.0",
"ide-ci",
"octocrab",
2022-07-01 04:58:14 +03:00
"serde",
"serde_json",
"serde_yaml 0.9.10",
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
"strum",
"tempfile",
"tokio 1.19.2",
"tracing",
"tracing-subscriber",
]
[[package]]
name = "enso-build-utilities"
version = "0.1.0"
dependencies = [
"path-clean",
2022-05-23 05:16:04 +03:00
"reqwest 0.10.10",
2022-08-27 01:25:34 +03:00
"serde",
2022-05-23 05:16:04 +03:00
]
[[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",
]
[[package]]
name = "enso-callback"
version = "0.1.0"
dependencies = [
"enso-prelude",
]
[[package]]
name = "enso-config"
version = "0.1.0"
dependencies = [
"config-reader",
"enso-logger",
"enso-prelude",
"ensogl",
"semver 1.0.9",
]
[[package]]
name = "enso-data-structures"
version = "0.2.0"
dependencies = [
"criterion",
"enso-prelude",
"failure",
2021-10-30 16:04:07 +03:00
"itertools 0.9.0",
"rustversion",
"serde",
"typenum",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "enso-debug-api"
version = "0.1.0"
dependencies = [
"derivative",
Profiling workflows (#3475) Define some workflows for batch-mode profiling. Implemented: - collapse nodes - create node - enter collapsed node - new project - open visualization They can currently be built and run with a command like: `./run.sh ide build --profiling-level=debug && dist/ide/linux-unpacked/enso --entry-point profile --workflow create_node --save-profile out.json` And the data can be displayed with: `dist/ide/linux-unpacked/enso --entry-point profiling_run_graph --load-profile out.json` Demo of recording and viewing a profile with a command-line one-liner: https://user-images.githubusercontent.com/1047859/169954795-2d9520ca-84f9-45d2-b83a-5063ebe6f718.mp4 See: https://www.pivotaltracker.com/story/show/182195399. # Important Notes - When defining workflows, two helpers are enough to allow us to tell when the action is really done: `Fixture::compile_new_shaders`, and `Fixture::backend_execution`. Often, it is appropriate to await both, but it depends on the task. - The shader compiler is now driven by a `Controller`; while the `Compiler` is reset if context is lost, the `Controller`'s state survives context loss. - A new `--load-profile` option supports specifying a profile by path when running `profiling_run_graph`. - Drop the `with_same_start` profiler interface; we ended up preferring a child profiler convention, and this interface was not implemented compatibly with the stricter data model we've had since the introduction of `profiler::data`. - Fix the noisy `rustfmt` output.
2022-06-01 21:01:16 +03:00
"futures 0.3.21",
"js-sys",
"wasm-bindgen",
"web-sys",
]
[[package]]
name = "enso-debug-scene"
version = "0.1.0"
dependencies = [
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
"debug-scene-component-group",
2022-06-22 18:39:32 +03:00
"debug-scene-component-list-panel-view",
"debug-scene-icons",
"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",
]
[[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",
"enso-web",
"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",
]
[[package]]
name = "enso-gui"
version = "0.1.0"
dependencies = [
"analytics",
"ast",
"bimap",
"console_error_panic_hook",
Virtual Entries in Component Browser (#3621) Add "text input" and "number input" virtual entries in the "Input" virtual component group in the Component Browser. The entries provide an easy way to put strings and numbers into a graph. https://www.pivotaltracker.com/story/show/181870589 #### Visuals See below for a video showing the "text input" and "number input" virtual entries in the "Input" component group in the "Favorites Data Science Tools" section of the Component Browser. Please note that the video also displays a few known issues that are present in the existing code and not introduced by this PR: - "Opening the Component Browser 2nd or later time flashes its last contents from the previous time" - reported as [issue 15 in PR 3530](https://github.com/enso-org/enso/pull/3530#pullrequestreview-1035698205) (which is [expected](https://github.com/enso-org/enso/pull/3530#issuecomment-1187676313) to be fixed by https://www.pivotaltracker.com/story/show/182610422). - The text of all the entries in the Component Browser does not show immediately, but the entries appear one by one instead (this is related to the performance of the current implementation of Component Browser and Text Area). - Selection in the Component Browser can show half-way between entries - reported as https://www.pivotaltracker.com/story/show/182713338. https://user-images.githubusercontent.com/273837/183472391-c14eeded-481f-492e-a1b8-b86f42faf0cd.mov # Important Notes - The virtual entries are not filtered by input type or return type. The filtering is expected to be implemented in https://www.pivotaltracker.com/story/show/182842444.
2022-08-17 16:28:07 +03:00
"const_format",
"convert_case 0.5.0",
"double-representation",
"engine-protocol",
"enso-callback",
"enso-config",
"enso-data-structures",
"enso-debug-api",
"enso-debug-scene",
"enso-frp",
"enso-logger",
"enso-prelude",
"enso-profiler",
"enso-shapely",
"enso-text",
"enso-web",
"ensogl",
"ensogl-component",
"ensogl-drop-manager",
"ensogl-examples",
"ensogl-hardcoded-theme",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"failure",
"flo_stream",
"futures 0.3.21",
"fuzzly",
"ide-view",
"ide-view-component-group",
"itertools 0.10.3",
"js-sys",
"json-rpc",
"mockall",
"nalgebra 0.26.2",
"parser",
"regex",
"semver 1.0.9",
"serde",
"serde_json",
"sha3",
"span-tree",
"uuid 0.8.2",
"wasm-bindgen",
"wasm-bindgen-futures",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
"web-sys",
"websocket",
]
2022-02-11 15:19:02 +03:00
[[package]]
name = "enso-integration-test"
version = "0.1.0"
dependencies = [
"approx 0.5.1",
"engine-protocol",
2022-02-11 15:19:02 +03:00
"enso-frp",
"enso-gui",
"enso-prelude",
"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 = [
"enso-prelude",
"enso-shapely",
2022-08-27 01:25:34 +03:00
"ifmt",
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",
"syn",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
2021-10-30 16:04:07 +03:00
]
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
[[package]]
name = "enso-metamodel"
version = "0.1.0"
dependencies = [
2022-08-27 01:25:34 +03:00
"bincode 1.3.3",
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
"derivative",
"derive_more",
]
[[package]]
name = "enso-metamodel-lexpr"
version = "0.1.0"
dependencies = [
2022-08-27 01:25:34 +03:00
"bincode 1.3.3",
"derivative",
"enso-metamodel",
"enso-reflect",
"lexpr",
"serde",
]
2021-10-30 16:04:07 +03:00
[[package]]
name = "enso-optics"
version = "0.2.0"
dependencies = [
"enso-prelude",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "enso-parser"
version = "0.1.0"
dependencies = [
2022-08-27 01:25:34 +03:00
"bincode 1.3.3",
"enso-data-structures",
"enso-metamodel",
"enso-metamodel-lexpr",
"enso-parser-syntax-tree-visitor",
"enso-prelude",
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
"enso-reflect",
"enso-shapely-macros",
"enso-types",
"lexpr",
2022-07-20 17:53:20 +03:00
"rand 0.8.5",
"rand_chacha 0.3.1",
"rand_distr 0.4.3",
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
"serde",
"serde_json",
"uuid 1.1.2",
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
]
[[package]]
name = "enso-parser-generate-java"
version = "0.1.0"
dependencies = [
"derivative",
"enso-metamodel",
"enso-parser",
"enso-prelude",
"enso-reflect",
]
[[package]]
name = "enso-parser-jni"
version = "0.1.0"
dependencies = [
2022-08-27 01:25:34 +03:00
"bincode 1.3.3",
"enso-parser",
"enso-prelude",
"jni",
]
[[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",
"assert_approx_eq",
2021-10-30 16:04:07 +03:00
"backtrace",
"boolinator",
"cfg-if 1.0.0",
"colored",
"derivative",
"derive_more",
"enclose",
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
"enso-reflect",
"enso-shapely",
2022-08-27 01:25:34 +03:00
"enso-web",
2021-10-30 16:04:07 +03:00
"failure",
"futures 0.3.21",
"ifmt",
"itertools 0.10.3",
2021-10-30 16:04:07 +03:00
"lazy_static",
"nalgebra 0.26.2",
"num",
2021-10-30 16:04:07 +03:00
"object 0.24.0",
"paste 1.0.7",
2021-10-30 16:04:07 +03:00
"serde",
"serde_json",
"shrinkwraprs 0.3.0",
"smallvec 1.8.0",
"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",
"weak-table",
2021-10-30 16:04:07 +03:00
"web-sys",
]
[[package]]
name = "enso-profiler"
version = "0.1.0"
dependencies = [
"enso-profiler-macros",
"enso-web",
"futures 0.3.21",
API for storing metadata (#3291) API for storing metadata. See: https://www.pivotaltracker.com/story/show/181149277 # Important Notes **New APIs**: - Storing metadata is implemented with `profiler::MetadataLogger`. - A full metadata storage/retrieval example is in [the top-level doctests](https://github.com/enso-org/enso/blob/wip/kw/profiling-metadata-api/lib/rust/profiler/data/src/lib.rs) for profiler::data, a crate which implements an API for profiling data consumers (it abstracts away the low-level details of the event log, and checks its invariants in the process) [after review of this new API here I'll open a PR to add it to the design doc]. **Implementation**: - `profiler::Event` is parameterized by a metadata type, so that different types of metadata can be dependency-injected into it. - A data consumer defines its metadata type as an enum of all the kinds of metadata it is interested in. - Producing the metadata enum is accomplished without defining its type (which would require dependencies from around the app): A `MetadataLogger` internally use a serialization helper `Variant` to serialize its variant of the metadata enum without knowledge of the other possible variants. **Performance impact**: still in the low ns/measurement range, comparable to pushing to a vec. *Note*: `LocalVecBuilder` is currently present under the name `Log`, which is accurate but probably too overloaded. I'd like to find the right name for it, document it with examples, and move it to its own crate under data-structures, but I don't want doing that to hold up this PR.
2022-02-28 12:55:56 +03:00
"serde",
"serde_json",
"wasm-bindgen",
]
API for storing metadata (#3291) API for storing metadata. See: https://www.pivotaltracker.com/story/show/181149277 # Important Notes **New APIs**: - Storing metadata is implemented with `profiler::MetadataLogger`. - A full metadata storage/retrieval example is in [the top-level doctests](https://github.com/enso-org/enso/blob/wip/kw/profiling-metadata-api/lib/rust/profiler/data/src/lib.rs) for profiler::data, a crate which implements an API for profiling data consumers (it abstracts away the low-level details of the event log, and checks its invariants in the process) [after review of this new API here I'll open a PR to add it to the design doc]. **Implementation**: - `profiler::Event` is parameterized by a metadata type, so that different types of metadata can be dependency-injected into it. - A data consumer defines its metadata type as an enum of all the kinds of metadata it is interested in. - Producing the metadata enum is accomplished without defining its type (which would require dependencies from around the app): A `MetadataLogger` internally use a serialization helper `Variant` to serialize its variant of the metadata enum without knowledge of the other possible variants. **Performance impact**: still in the low ns/measurement range, comparable to pushing to a vec. *Note*: `LocalVecBuilder` is currently present under the name `Log`, which is accurate but probably too overloaded. I'd like to find the right name for it, document it with examples, and move it to its own crate under data-structures, but I don't want doing that to hold up this PR.
2022-02-28 12:55:56 +03:00
[[package]]
name = "enso-profiler-data"
version = "0.1.0"
dependencies = [
"derivative",
"enso-prelude",
API for storing metadata (#3291) API for storing metadata. See: https://www.pivotaltracker.com/story/show/181149277 # Important Notes **New APIs**: - Storing metadata is implemented with `profiler::MetadataLogger`. - A full metadata storage/retrieval example is in [the top-level doctests](https://github.com/enso-org/enso/blob/wip/kw/profiling-metadata-api/lib/rust/profiler/data/src/lib.rs) for profiler::data, a crate which implements an API for profiling data consumers (it abstracts away the low-level details of the event log, and checks its invariants in the process) [after review of this new API here I'll open a PR to add it to the design doc]. **Implementation**: - `profiler::Event` is parameterized by a metadata type, so that different types of metadata can be dependency-injected into it. - A data consumer defines its metadata type as an enum of all the kinds of metadata it is interested in. - Producing the metadata enum is accomplished without defining its type (which would require dependencies from around the app): A `MetadataLogger` internally use a serialization helper `Variant` to serialize its variant of the metadata enum without knowledge of the other possible variants. **Performance impact**: still in the low ns/measurement range, comparable to pushing to a vec. *Note*: `LocalVecBuilder` is currently present under the name `Log`, which is accurate but probably too overloaded. I'd like to find the right name for it, document it with examples, and move it to its own crate under data-structures, but I don't want doing that to hold up this PR.
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",
"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",
]
[[package]]
name = "enso-profiler-flame-graph"
version = "0.1.0"
dependencies = [
"enso-profiler",
"enso-profiler-data",
"futures 0.3.21",
]
[[package]]
name = "enso-profiler-macros"
version = "0.1.0"
dependencies = [
"Inflector",
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
]
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
[[package]]
name = "enso-reflect"
version = "0.1.0"
dependencies = [
"derivative",
"enso-metamodel",
"enso-reflect-macros",
]
[[package]]
name = "enso-reflect-macros"
version = "0.1.0"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
2021-10-30 16:04:07 +03:00
[[package]]
name = "enso-shapely"
version = "0.2.0"
dependencies = [
"derivative",
"enso-prelude",
"enso-shapely-macros",
2021-10-30 16:04:07 +03:00
"paste 0.1.18",
"rustversion",
"shrinkwraprs 0.3.0",
2022-08-27 01:25:34 +03:00
"wasm-bindgen",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
2022-08-27 01:25:34 +03:00
"web-sys",
2021-10-30 16:04:07 +03:00
]
[[package]]
name = "enso-shapely-macros"
version = "0.2.1"
dependencies = [
"Inflector",
"boolinator",
"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",
"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]]
name = "enso-shortcuts"
version = "0.1.0"
2021-01-25 17:41:20 +03:00
dependencies = [
"enso-automata",
"enso-frp",
"enso-logger",
"enso-prelude",
"enso-web",
"js-sys",
"nalgebra 0.26.2",
"serde",
"serde_json",
"wasm-bindgen",
"web-sys",
2021-01-25 17:41:20 +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]]
name = "enso-types"
2021-10-30 16:04:07 +03:00
version = "0.1.0"
dependencies = [
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
"enso-reflect",
"nalgebra 0.26.2",
"num-traits",
"paste 1.0.7",
Parser: Transpile Rust AST types to Java types (#3555) Implement generation of Java AST types from the Rust AST type definitions, with support for deserializing in Java syntax trees created in Rust. ### New Libraries #### `enso-reflect` Implements a `#[derive(Reflect)]` macro to enable runtime analysis of datatypes. Macro interface includes helper attributes; **the Rust types and the `reflect` attributes applied to them fully determine the Java types** ultimately produced (by `enso-metamodel`). This is the most important API, as it is used in the subject crates (`enso-parser`, and dependencies with types used in the AST). [Module docs](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/reflect/macros/src/lib.rs). #### `enso-metamodel` Provides data models for data models in Rust/Java/Meta (a highly-abstracted language-independent model--I have referred to it before as the "generic representation", but that was an overloaded term). The high-level interface consists of operations on data models, and between them. For example, the only operations needed by [the binary that drives datatype transpilation](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/main.rs) are: `rust::to_meta`, `java::from_meta`, `java::transform::optional_to_null`, `java::to_syntax`. The low-level interface consists of direct usage of the datatypes; this is used by [the module that implements some serialization overrides](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/parser/generate-java/src/serialization.rs) (so that the Java interface to `Code` references can produce `String`s on demand based on serialized offset/length pairs). The serialization override mechanism is based on customizing, not replacing, the generated deserialization methods, so as to be as robust as possible to changes in the Rust source or in the transpilation process. ### Important Notes - Rust/Java serialization is exhaustively tested for structural compatibility. A function [`metamodel::meta::serialization::testcases`](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/metamodel/src/meta/serialization.rs) uses `reflect`-derived data to generate serialized representations of ASTs to use as test cases. Its should-accept cases cover every type a tree can contain; it also produces a representative set of should-reject cases. A Rust `#[test]` confirms that these cases are accepted/rejected as expected, and generated Java tests (see Binaries below) check the generated Java deserialization code against the same test cases. - Deserializing `Code` is untested. The mechanism is in place (in Rust, we serialize only the offset/length of the `Cow`; in Java, during deserialization we obtain a context object holding a buffer for all string data; the accessor generated in Java uses the buffer and the offset/length to return `String`s), but it will be easier to test once we have implemented actually parsing something and instantiating the `Cow`s with source code. - `#[tagged_enum]` [now supports](https://github.com/enso-org/enso/blob/wip/kw/parser/ast-transpiler/lib/rust/shapely/macros/src/tagged_enum.rs#L36-L51) control over what is done with container-level attributes; they can be applied to the container and variants (default), only to the container, or only to variants. - Generation of `sealed` classes is supported, but currently disabled by `TARGET_VERSION` in `metamodel::java::syntax` so that tests don't require Java 15 to run. (The same logic is run either way; there is a shallow difference in output.) ### Binaries The `enso-parser-generate-java` crate defines several binaries: - `enso-parser-generate-java`: Performs the transpilation; after integration, this will be invoked by the build script. - `java-tests`: Generates the Java code that tests format deserialization; after integration this command will be invoked by the build script, and its Java output compiled and run during testing. - `graph-rust`/`graph-meta`/`graph-java`: Produce GraphViz representations of data models in different typesystems; these are for developing and understanding model transformations. Until integration, a **script regenerates the Java and runs the format tests: `./tools/parser_generate_java.sh`**. The generated code can be browsed in `target/generated_java`.
2022-07-07 05:46:42 +03:00
"serde",
2021-10-30 16:04:07 +03:00
]
[[package]]
name = "enso-web"
version = "0.1.0"
dependencies = [
"async-std",
"console_error_panic_hook",
2022-08-27 01:25:34 +03:00
"derivative",
"enso-debug-api",
2022-08-27 01:25:34 +03:00
"enso-shapely",
"failure",
"gloo-timers",
"js-sys",
"nalgebra 0.26.2",
2022-08-27 01:25:34 +03:00
"tracing",
"wasm-bindgen",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
"web-sys",
]
2021-10-30 16:04:07 +03:00
[[package]]
name = "ensogl"
2021-10-30 16:04:07 +03:00
version = "0.1.0"
dependencies = [
"ensogl-core",
"ensogl-text",
2021-10-30 16:04:07 +03:00
]
Return creating node with (+) button & fix a regression (#3338) * Creating a new node with the (+) button (#3278) [The Task](https://www.pivotaltracker.com/story/show/180887253) A new (+) button on the left-bottom corner appeared. It may be clicked to open searcher in the middle of the scene, as an alternative to tab key. https://user-images.githubusercontent.com/3919101/154514279-7972ed6a-0203-47cb-9a09-82dba948cf2f.mp4 * The window_control_buttons::common was extracted to separate crate `ensogl-component-button` almost without change. * This includes a severe refactoring of adding nodes in general in the Graph Editor. The whole responsibility of adding new nodes (and starting their editing) was moved to Graph Editor - the Project View only reacts for GE events to show searcher properly. * The status bar was moved from the bottom-left corner to the middle-top of the scene. It does not collide with (+) button, and plays "notification" role anyway. * The `interface` debug scene was buggy. The problem was with one expression's span-tree. When I replaced it, the scene works. * I've removed "new searcher" API, as it is completely outdated. * I've changed code owners of integration tests to GUI team, as it is the team writing mostly the integration tests (int rust) * Fix regression #181528359 * Add docs & remove unused function * Fix & enable native Rust tests * Fix formatting Co-authored-by: Adam Obuchowicz <adam.obuchowicz@enso.org> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
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]]
name = "ensogl-component"
version = "0.1.0"
dependencies = [
Return creating node with (+) button & fix a regression (#3338) * Creating a new node with the (+) button (#3278) [The Task](https://www.pivotaltracker.com/story/show/180887253) A new (+) button on the left-bottom corner appeared. It may be clicked to open searcher in the middle of the scene, as an alternative to tab key. https://user-images.githubusercontent.com/3919101/154514279-7972ed6a-0203-47cb-9a09-82dba948cf2f.mp4 * The window_control_buttons::common was extracted to separate crate `ensogl-component-button` almost without change. * This includes a severe refactoring of adding nodes in general in the Graph Editor. The whole responsibility of adding new nodes (and starting their editing) was moved to Graph Editor - the Project View only reacts for GE events to show searcher properly. * The status bar was moved from the bottom-left corner to the middle-top of the scene. It does not collide with (+) button, and plays "notification" role anyway. * The `interface` debug scene was buggy. The problem was with one expression's span-tree. When I replaced it, the scene works. * I've removed "new searcher" API, as it is completely outdated. * I've changed code owners of integration tests to GUI team, as it is the team writing mostly the integration tests (int rust) * Fix regression #181528359 * Add docs & remove unused function * Fix & enable native Rust tests * Fix formatting Co-authored-by: Adam Obuchowicz <adam.obuchowicz@enso.org> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
2022-03-16 21:02:47 +03:00
"ensogl-button",
"ensogl-drop-down-menu",
"ensogl-drop-manager",
"ensogl-file-browser",
"ensogl-flame-graph",
"ensogl-grid-view",
"ensogl-label",
"ensogl-list-view",
"ensogl-scroll-area",
"ensogl-scrollbar",
"ensogl-selector",
"ensogl-shadow",
"ensogl-text",
"ensogl-toggle-button",
"ensogl-tooltip",
]
2021-10-30 16:04:07 +03:00
2021-01-25 17:41:20 +03:00
[[package]]
name = "ensogl-core"
version = "0.1.0"
2021-01-25 17:41:20 +03:00
dependencies = [
"Inflector",
"bit_field",
"code-builder",
"console_error_panic_hook",
"enso-callback",
"enso-data-structures",
"enso-debug-api",
"enso-frp",
"enso-generics",
"enso-logger",
"enso-optics",
"enso-prelude",
"enso-profiler",
"enso-shapely",
"enso-shortcuts",
"enso-types",
"enso-web",
"ensogl-text-embedded-fonts",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"enum_dispatch",
"failure",
"itertools 0.10.3",
"js-sys",
"nalgebra 0.26.2",
"num-traits",
"num_enum",
"rustc-hash",
2022-05-23 05:16:04 +03:00
"semver 1.0.9",
"serde",
"shrinkwraprs 0.3.0",
"smallvec 1.8.0",
2021-01-25 17:41:20 +03:00
"typenum",
"wasm-bindgen",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
"web-sys",
]
[[package]]
name = "ensogl-derive-theme"
version = "0.1.0"
dependencies = [
"ensogl-core",
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "ensogl-drop-down-menu"
version = "0.1.0"
dependencies = [
"enso-frp",
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-list-view",
"ensogl-text",
]
[[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",
"web-sys",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "ensogl-example-animation"
version = "0.1.0"
2021-01-25 17:41:20 +03:00
dependencies = [
"enso-frp",
"enso-prelude",
"ensogl-core",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-complex-shape-system"
version = "0.1.0"
dependencies = [
"ensogl-core",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-custom-shape-system"
version = "0.1.0"
dependencies = [
"enso-frp",
"enso-profiler",
"ensogl-core",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-dom-symbols"
version = "0.1.0"
dependencies = [
"ensogl-core",
"nalgebra 0.26.2",
"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",
]
[[package]]
name = "ensogl-example-easing-animator"
version = "0.1.0"
dependencies = [
"ensogl-core",
"js-sys",
"nalgebra 0.26.2",
"wasm-bindgen",
"web-sys",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "ensogl-example-glyph-system"
version = "0.1.0"
dependencies = [
"ensogl-core",
"ensogl-text",
"ensogl-text-embedded-fonts",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-grid-view"
version = "0.1.0"
dependencies = [
"enso-frp",
"enso-text",
"ensogl-core",
"ensogl-grid-view",
"ensogl-hardcoded-theme",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"itertools 0.10.3",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-list-view"
version = "0.1.0"
dependencies = [
"enso-frp",
"enso-text",
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-list-view",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-mouse-events"
version = "0.1.0"
dependencies = [
"enso-frp",
"ensogl-core",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-profiling-run-graph"
version = "0.1.0"
dependencies = [
Profiling workflows (#3475) Define some workflows for batch-mode profiling. Implemented: - collapse nodes - create node - enter collapsed node - new project - open visualization They can currently be built and run with a command like: `./run.sh ide build --profiling-level=debug && dist/ide/linux-unpacked/enso --entry-point profile --workflow create_node --save-profile out.json` And the data can be displayed with: `dist/ide/linux-unpacked/enso --entry-point profiling_run_graph --load-profile out.json` Demo of recording and viewing a profile with a command-line one-liner: https://user-images.githubusercontent.com/1047859/169954795-2d9520ca-84f9-45d2-b83a-5063ebe6f718.mp4 See: https://www.pivotaltracker.com/story/show/182195399. # Important Notes - When defining workflows, two helpers are enough to allow us to tell when the action is really done: `Fixture::compile_new_shaders`, and `Fixture::backend_execution`. Often, it is appropriate to await both, but it depends on the task. - The shader compiler is now driven by a `Controller`; while the `Compiler` is reset if context is lost, the `Controller`'s state survives context loss. - A new `--load-profile` option supports specifying a profile by path when running `profiling_run_graph`. - Drop the `with_same_start` profiler interface; we ended up preferring a child profiler convention, and this interface was not implemented compatibly with the stricter data model we've had since the introduction of `profiler::data`. - Fix the noisy `rustfmt` output.
2022-06-01 21:01:16 +03:00
"enso-debug-api",
"enso-frp",
"enso-profiler",
"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",
"enso-profiler-flame-graph",
"enso-web",
"ensogl-core",
"ensogl-flame-graph",
"ensogl-hardcoded-theme",
"ensogl-sequence-diagram",
"ensogl-text",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"ensogl-tooltip",
"futures 0.3.21",
"qstring",
"serde",
"url 2.2.2",
"wasm-bindgen",
"wasm-bindgen-futures",
"web-sys",
]
[[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",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"ensogl-tooltip",
"futures 0.3.21",
"wasm-bindgen",
"wasm-bindgen-futures",
"web-sys",
]
[[package]]
name = "ensogl-example-scroll-area"
version = "0.1.0"
dependencies = [
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-scroll-area",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-shape-system"
version = "0.1.0"
dependencies = [
"enso-profiler",
"ensogl-core",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-slider"
version = "0.1.0"
dependencies = [
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-selector",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"wasm-bindgen",
]
[[package]]
name = "ensogl-example-sprite-system"
version = "0.1.0"
dependencies = [
2022-03-04 17:13:23 +03:00
"enso-web",
"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 = [
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-text",
"ensogl-text-embedded-fonts",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"wasm-bindgen",
]
[[package]]
name = "ensogl-examples"
version = "0.1.0"
dependencies = [
"ensogl-example-animation",
"ensogl-example-complex-shape-system",
"ensogl-example-custom-shape-system",
"ensogl-example-dom-symbols",
"ensogl-example-drop-manager",
"ensogl-example-easing-animator",
"ensogl-example-glyph-system",
"ensogl-example-grid-view",
"ensogl-example-list-view",
"ensogl-example-mouse-events",
"ensogl-example-profiling-run-graph",
"ensogl-example-render-profile-flamegraph",
"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",
]
[[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",
]
[[package]]
name = "ensogl-grid-view"
version = "0.1.0"
dependencies = [
"approx 0.5.1",
"enso-frp",
"ensogl-core",
"ensogl-hardcoded-theme",
"ensogl-scroll-area",
"ensogl-shadow",
"ensogl-text",
"itertools 0.10.3",
"segment-tree",
]
[[package]]
name = "ensogl-gui-component"
version = "0.1.0"
dependencies = [
"enso-frp",
"enso-logger",
"ensogl-core",
"float_eq",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "ensogl-hardcoded-theme"
version = "0.1.0"
dependencies = [
"ensogl-core",
]
2021-01-25 17:41:20 +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 = [
"approx 0.5.1",
"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",
]
[[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",
]
[[package]]
name = "ensogl-shadow"
version = "0.1.0"
dependencies = [
"ensogl-core",
"ensogl-hardcoded-theme",
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "ensogl-text"
version = "0.1.0"
2021-01-25 17:41:20 +03:00
dependencies = [
2022-08-27 01:25:34 +03:00
"bincode 2.0.0-rc.1",
"const_format",
"enso-frp",
"enso-prelude",
"enso-shapely",
"enso-text",
"enso-types",
"ensogl-core",
"ensogl-text-embedded-fonts",
2022-08-27 01:25:34 +03:00
"ensogl-text-font-family",
"ensogl-text-msdf",
"ordered-float",
"owned_ttf_parser",
"serde",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
"xi-rope",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "ensogl-text-embedded-fonts"
version = "0.1.0"
2021-01-25 17:41:20 +03:00
dependencies = [
"enso-build",
"enso-build-utilities",
"enso-prelude",
2022-08-27 01:25:34 +03:00
"ensogl-text-font-family",
"owned_ttf_parser",
"tokio 1.19.2",
"zip 0.5.13",
2021-01-25 17:41:20 +03:00
]
[[package]]
2022-08-27 01:25:34 +03:00
name = "ensogl-text-font-family"
version = "0.1.0"
2022-08-27 01:25:34 +03:00
dependencies = [
"enso-prelude",
"owned_ttf_parser",
]
2021-10-30 16:04:07 +03:00
[[package]]
2022-08-27 01:25:34 +03:00
name = "ensogl-text-msdf"
version = "0.1.0"
2021-10-30 16:04:07 +03:00
dependencies = [
"enso-build-utilities",
"enso-prelude",
2022-08-27 01:25:34 +03:00
"enso-types",
"ensogl-text-embedded-fonts",
2022-08-27 01:25:34 +03:00
"ensogl-text-font-family",
"failure",
"futures 0.3.21",
"js-sys",
"nalgebra 0.26.2",
2022-08-27 01:25:34 +03:00
"owned_ttf_parser",
"serde",
"wasm-bindgen",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "ensogl-toggle-button"
version = "0.1.0"
dependencies = [
"enso-frp",
"ensogl-core",
]
[[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]]
name = "enum_dispatch"
version = "0.3.8"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0eb359f1476bf611266ac1f5355bc14aeca37b299d0ebccc038ee7058891c9cb"
2021-01-25 17:41:20 +03:00
dependencies = [
"once_cell",
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"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",
]
[[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]]
name = "failure"
version = "0.1.8"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d32e9bd16cc02eae7db7ef620b392808b89f6a5e16bb3497d159c6b92a0f4f86"
dependencies = [
"backtrace",
"failure_derive",
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "aa4da3c766cd7a0db8242e326e9e4e081edd567072893ed320008189715366a4"
2021-01-25 17:41:20 +03:00
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
"synstructure",
2021-01-25 17:41:20 +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]]
name = "flatbuffers"
version = "0.5.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ea0c34f669be9911826facafe996adfda978aeee67285a13556869e2d8b8331f"
dependencies = [
"smallvec 0.6.14",
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "fdce2ac68e3bccc405e0255e9b56d7841c06f6c7d36a8aa8b2966fbb3995bd9a"
2021-01-25 17:41:20 +03:00
dependencies = [
"log 0.4.17",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
dependencies = [
"cfg-if 1.0.0",
"crc32fast",
"libc",
"miniz_oxide",
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "b02e0d3667b27514149c1ac9b372d700f3e6df4bbaf6b7c5df12915de2996049"
dependencies = [
"futures 0.3.21",
"smallvec 1.8.0",
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "e1267f4ac4f343772758f7b1bdcbe767c218bbab93bb432acbf5162bbf85a6c4"
dependencies = [
"num-traits",
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
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]]
name = "fnv"
version = "1.0.7"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3f9eec918d3f24069decb9af1554cad7c880e2da24a9afd88aca000531ab82c1"
2021-01-25 17:41:20 +03:00
2021-10-30 16:04:07 +03:00
[[package]]
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"
checksum = "f6f339eb8adc052cd2ca78910fda869aefa38d22d5cb648e6485e4d3fc06f3b1"
2021-10-30 16:04:07 +03:00
dependencies = [
"foreign-types-shared",
2021-10-30 16:04:07 +03:00
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "00b0228411908ca8685dba7fc2cdd70ec9990a6e753e89b6ac91a84c40fbaf4b"
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "5fc25a87fa4fd2094bffb06925852034d90a17f0d1e05197d4956d3555752191"
2021-01-25 17:41:20 +03:00
dependencies = [
"matches",
"percent-encoding 2.1.0",
2021-01-25 17:41:20 +03:00
]
[[package]]
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]]
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"
checksum = "a06f77d526c1a601b7c4cdd98f54b5eaabffc14d5f2f0296febdc7f357c6d3ba"
2021-10-30 16:04:07 +03:00
[[package]]
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"
checksum = "2e9763c69ebaae630ba35f74888db465e49e259ba1bc0eda7d06f4a067615d82"
2021-10-30 16:04:07 +03:00
dependencies = [
"bitflags",
"fuchsia-zircon-sys",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "3dcaa9ae7725d12cdb85b3ad99a434db70b468c09ded17e012d86b5c1010f7a7"
2021-01-25 17:41:20 +03:00
[[package]]
name = "futures"
version = "0.1.31"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3a471a38ef8ed83cd6e40aa59c1ffe17db6855c18e3604d9c4ed8c08ebc28678"
2021-01-25 17:41:20 +03:00
2021-10-30 16:04:07 +03:00
[[package]]
name = "futures"
version = "0.3.21"
2021-10-30 16:04:07 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f73fe65f54d1e12b726f517d3e2135ca3125a437b6d998caf1962961f7172d9e"
2021-10-30 16:04:07 +03:00
dependencies = [
"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]]
name = "futures-channel"
version = "0.3.21"
2021-10-30 16:04:07 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c3083ce4b914124575708913bca19bfe887522d6e2e6d0952943f5eac4a74010"
2021-10-30 16:04:07 +03:00
dependencies = [
"futures-core",
"futures-sink",
2021-10-30 16:04:07 +03:00
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "futures-core"
version = "0.3.21"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0c09fd04b7e4073ac7156a9539b57a484a8ea920f79c7c675d05d289ab6110d3"
2021-10-30 16:04:07 +03:00
[[package]]
name = "futures-executor"
version = "0.3.21"
2021-10-30 16:04:07 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9420b90cfa29e327d0429f19be13e7ddb68fa1cccb09d65e5706b8c7a749b8a6"
2021-10-30 16:04:07 +03:00
dependencies = [
"futures-core",
"futures-task",
"futures-util",
2021-10-30 16:04:07 +03:00
]
[[package]]
name = "futures-io"
version = "0.3.21"
2021-10-30 16:04:07 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
"pin-project-lite 0.2.9",
"waker-fn",
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "futures-macro"
version = "0.3.21"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "33c1e13800337f4d4d7a316bf45a567dbcb6ffe087f16424852d97e97a91f512"
2021-01-25 17:41:20 +03:00
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "futures-sink"
version = "0.3.21"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "21163e139fa306126e6eedaf49ecdb4588f939600f0b1e770f4205ee4b7fa868"
[[package]]
name = "futures-task"
version = "0.3.21"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "57c66a976bf5909d801bbef33416c41372779507e7a6b3a5e25e4749c58f776a"
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"
[[package]]
name = "futures-util"
version = "0.3.21"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d8b7abd5d659d9b90c8cba917f6ec750a74e2dc23902ef9cd4cc8c8b22e6036a"
2021-01-25 17:41:20 +03:00
dependencies = [
"futures-channel",
"futures-core",
"futures-io",
"futures-macro",
"futures-sink",
"futures-task",
"memchr",
"pin-project-lite 0.2.9",
"pin-utils",
"slab",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "fuzzly"
version = "0.1.0"
2021-01-25 17:41:20 +03:00
dependencies = [
"enso-prelude",
2021-10-30 16:04:07 +03:00
]
[[package]]
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"
checksum = "ffdf9f34f1447443d37393cc6c2b8313aebddcd96906caf34e54c68d8e57d7bd"
2021-10-30 16:04:07 +03:00
dependencies = [
"typenum",
2021-10-30 16:04:07 +03:00
]
[[package]]
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"
checksum = "f797e67af32588215eaaab8327027ee8e71b9dd0b2b26996aedf20c030fce309"
2021-10-30 16:04:07 +03:00
dependencies = [
"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]]
name = "getrandom"
version = "0.1.16"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8fc3cb4d91f53b50155bdcfd23f6a4c39ae1969c2ae85982b135750cccaf5fce"
2021-01-25 17:41:20 +03:00
dependencies = [
"cfg-if 1.0.0",
"libc",
"wasi 0.9.0+wasi-snapshot-preview1",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "getrandom"
version = "0.2.7"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4eb1a864a501629691edf6c15a593b7a51eebaa1e8468e9ddc623de7c9b58ec6"
2021-01-25 17:41:20 +03:00
dependencies = [
"cfg-if 1.0.0",
"js-sys",
2021-01-25 17:41:20 +03:00
"libc",
"wasi 0.11.0+wasi-snapshot-preview1",
"wasm-bindgen",
2021-01-25 17:41:20 +03:00
]
[[package]]
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 3.8.1",
2022-05-23 05:16:04 +03:00
"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
[[package]]
2022-05-23 05:16:04 +03:00
name = "graphql_client_codegen"
version = "0.10.0"
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-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]]
name = "h2"
version = "0.2.7"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5e4728fd124914ad25e99e3d15a9361a879f6620f63cb56bbb08f95abb97a535"
2021-01-25 17:41:20 +03:00
dependencies = [
"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",
"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]]
name = "half"
version = "1.8.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "eabb4a44450da02c90444cf74558da904edde8fb4e9035a9a6a4e15445af0bd7"
[[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",
]
[[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]]
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"
checksum = "62b467343b94ba476dcb2500d242dadbb39557df889310ac77c5d99100aaac33"
2021-01-25 17:41:20 +03:00
dependencies = [
"libc",
2021-01-25 17:41:20 +03:00
]
2021-10-30 16:04:07 +03:00
[[package]]
name = "hex"
version = "0.4.3"
2021-10-30 16:04:07 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7f24254aa9a54b5c858eaee2f5bccdb46aaf0e486a595ed5fd8f86ba55232a70"
2021-10-30 16:04:07 +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]]
name = "http"
version = "0.2.8"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "75f43d41e26995c17e71ee126451dd3941010b0514a81a9d11f3b341debc2399"
2021-01-25 17:41:20 +03:00
dependencies = [
"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]]
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"
checksum = "13d5ff830006f7646652e057693569bfe0d51760c0085a071769d142a205111b"
2021-01-25 17:41:20 +03:00
dependencies = [
"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]]
name = "httparse"
version = "1.7.1"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "496ce29bb5a52785b44e0f7ca2847ae0bb839c9bd28f69acac9b99d461c0c04c"
2021-01-25 17:41:20 +03:00
[[package]]
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"
[[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",
"log 0.3.9",
"mime 0.2.6",
"num_cpus",
2022-05-23 05:16:04 +03:00
"time 0.1.44",
"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",
"http",
2022-05-23 05:16:04 +03:00
"http-body 0.3.1",
"httparse",
2022-05-23 05:16:04 +03:00
"httpdate 0.3.2",
"itoa 0.4.8",
"pin-project",
"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",
"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",
]
[[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",
"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 = [
"base64 0.10.1",
2022-05-23 05:16:04 +03:00
"bytes 1.1.0",
"http",
"httpdate 0.3.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"
source = "git+https://github.com/enso-org/ci-build?branch=develop#93d7afc1af0ad528444157943c24f9abb5d0b955"
2022-05-23 05:16:04 +03:00
dependencies = [
"anyhow",
"async-compression",
"async-trait",
2022-08-27 01:25:34 +03:00
"bincode 1.3.3",
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 0.34.0",
2022-05-23 05:16:04 +03:00
"cfg-if 1.0.0",
"chrono",
"clap 3.1.18",
"convert_case 0.5.0",
2022-07-01 04:58:14 +03:00
"cron",
2022-05-23 05:16:04 +03:00
"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",
"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 0.9.10",
2022-05-23 05:16:04 +03:00
"sha2",
"shrinkwraprs 0.3.0",
"snafu",
"strum",
2022-05-23 05:16:04 +03:00
"symlink",
"syn",
"sysinfo 0.23.13",
2022-05-23 05:16:04 +03:00
"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",
"tokio-util 0.7.2",
2022-05-23 05:16:04 +03:00
"tracing",
"tracing-subscriber",
"unicase 2.6.0",
"url 2.2.2",
"uuid 1.1.2",
2022-05-23 05:16:04 +03:00
"walkdir",
"which",
"whoami",
"wiremock",
"zip 0.6.2",
2022-05-23 05:16:04 +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",
"ensogl-component",
"ensogl-gui-component",
"ensogl-hardcoded-theme",
"ensogl-text",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"ide-view-component-browser",
"ide-view-graph-editor",
"js-sys",
"multi-map",
"nalgebra 0.26.2",
"ordered-float",
"parser",
"serde",
"serde_json",
"span-tree",
"uuid 0.8.2",
"wasm-bindgen",
"web-sys",
"welcome-screen",
]
[[package]]
name = "ide-view-component-browser"
version = "0.1.0"
dependencies = [
"enso-prelude",
"ensogl-text",
"ide-view-component-group",
"ide-view-component-list-panel",
]
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
[[package]]
name = "ide-view-component-group"
version = "0.1.0"
dependencies = [
"enso-frp",
"ensogl",
2022-06-22 18:39:32 +03:00
"ensogl-core",
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
"ensogl-gui-component",
"ensogl-hardcoded-theme",
"ensogl-label",
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
"ensogl-list-view",
Fully visible group name in partially scrolled Component Group View (#3447) [ci no changelog needed] [Task link](https://www.pivotaltracker.com/story/show/181725003) This PR implements a fully visible component group header while scrolling the group (using the ScrollArea). The header moves in sync with scrolling movements (using new `set_header_pos` FRP input), so it looks like the component group is scrolled. ScrollArea masks the "scrolled" entries above the header. This design allows a fully visible header even though our renderer doesn't support nested layers masking yet. The screencast: https://user-images.githubusercontent.com/6566674/168320360-2c2017b2-0ef5-42ce-9c79-82b9641c1d73.mp4 The most recent one, with the updated demo scene from develop: https://user-images.githubusercontent.com/6566674/168555268-8552c4b0-f887-4388-89a1-e65ddf668be6.mp4 # Important Notes - I fixed the API of the list view so now it supports non-hardcoded scene layers (previously it did not). I also believe it was implemented incorrectly. - I've found a [pretty weird bug](https://www.pivotaltracker.com/story/show/182193824): the component group inside the ScrollArea is invisible unless I add some arbitrary shape to the scroll area content. I use a `transparent_circle` for this purpose in the demo scene. The bug is probably related to masking the sublayers, though I wasn't able to reproduce it properly on a simpler example. - The selection box is removed from the demo scene as agreed with @farmaazon . The correct implementation has proven to be much harder than I expected, and we will implement another approach in a separate PR. - I also modified the `shadow::Parameters` so that it uses `Var`s instead of plain values.
2022-05-17 16:52:08 +03:00
"ensogl-shadow",
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
"ensogl-text",
"failure",
Component Group View with static header and without icons (#3373) Add an initial version of the visual component for displaying the Component Group View. The component contains a header (for displaying the Group Name) and a list of labels (for displaying the component names). https://www.pivotaltracker.com/story/show/181724889 #### Visuals A screenshot from a debug scene demonstrating the component: <img width="251" alt="Screenshot 2022-04-13 at 20 07 56" src="https://user-images.githubusercontent.com/273837/163243304-21c3ad78-4813-4368-b3bb-844d979da699.png"> Screenshots from other debug scenes (`list_view` and `text_area`), demonstrating that the other components still display correctly: <img width="202" alt="Screenshot 2022-04-13 at 20 08 56" src="https://user-images.githubusercontent.com/273837/163243428-de9dc1c7-5a9f-45e0-9325-db60cece9768.png"> <img width="403" alt="Screenshot 2022-04-13 at 20 08 48" src="https://user-images.githubusercontent.com/273837/163243432-895061d9-5bd9-4349-8679-eb63b0f6724d.png"> A screenshot of the Node Searcher's list, showing that long entries in a ListView are now truncated, and an ellipsis character is added in place of removed characters: <img width="651" alt="Screenshot 2022-04-13 at 20 10 16" src="https://user-images.githubusercontent.com/273837/163243664-5b671969-7aa0-4bef-8fd2-825602d85848.png"> # Important Notes - Adding support for the text truncation feature in `ListView` required some changes in the`list_view::Entry`-related APIs. - An embedded font was added (DejaVuSans-Bold) for use in the Component Group View debug scene, and 5 unused embedded fonts were removed.
2022-04-14 13:37:40 +03:00
]
[[package]]
name = "ide-view-component-list-panel"
version = "0.1.0"
dependencies = [
"approx 0.5.1",
"enso-frp",
"ensogl-core",
"ensogl-derive-theme",
"ensogl-grid-view",
"ensogl-gui-component",
"ensogl-hardcoded-theme",
"ensogl-list-view",
"ensogl-scroll-area",
"ensogl-selector",
"ensogl-shadow",
"ensogl-text",
"ide-view-component-group",
"num_enum",
"ordered-float",
]
[[package]]
name = "ide-view-graph-editor"
version = "0.1.0"
dependencies = [
"analytics",
"ast",
"base64 0.13.0",
"bimap",
"engine-protocol",
"enso-config",
"enso-frp",
"enso-logger",
"enso-prelude",
"enso-shapely",
"enso-text",
"ensogl",
"ensogl-component",
"ensogl-drop-manager",
"ensogl-hardcoded-theme",
2022-08-27 01:25:34 +03:00
"ensogl-text-msdf",
"failure",
"js-sys",
"nalgebra 0.26.2",
"ordered-float",
"serde",
"serde_json",
"sourcemap",
"span-tree",
"uuid 0.8.2",
"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"
[[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",
]
[[package]]
name = "if_chain"
version = "1.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cb56e1aa765b4b4f3aadfab769793b7087bb03a4ea4920644a6d238e2df5b9ed"
[[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",
"regex",
"syn",
]
[[package]]
name = "indexmap"
version = "1.9.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "10a35a97730320ffe8e2d410b5d3b69279b98d2c14bdb8b70ea89ecf7888d41e"
dependencies = [
"autocfg 1.1.0",
"hashbrown",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "indicatif"
version = "0.17.0-rc.11"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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"
[[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",
]
[[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"
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"
[[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"
version = "0.10.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a9a9d19fa1e79b6215ff29b9d6880b706147f16e9b1dbb1e4e5947b5b02bc5e3"
dependencies = [
"either",
]
[[package]]
name = "itoa"
version = "0.4.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b71991ff56294aa922b450139ee08b3bfc70982c6b2c7562771375cf73542dd4"
[[package]]
name = "itoa"
2022-05-23 05:16:04 +03:00
version = "1.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
2022-05-23 05:16:04 +03:00
checksum = "112c678d4050afce233f4f2852bb2eb519230b3cf12f33585275537d7e41578d"
[[package]]
name = "jni"
version = "0.19.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c6df18c2e3db7e453d3c6ac5b3e9d5182664d28788126d39b91f2d1e22b017ec"
dependencies = [
"cesu8",
"combine 4.6.4",
"jni-sys",
"log 0.4.17",
"thiserror",
"walkdir",
]
[[package]]
name = "jni-sys"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8eaf4bc02d17cbdd7ff4c7438cafcdf7fb9a4613313ad11b4f8fefe7d3fa0130"
[[package]]
name = "jobserver"
version = "0.1.24"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "af25a77299a7f711a01975c35a6a424eb6862092cc2d6c72c4ed6cbc56dfc1fa"
dependencies = [
"libc",
]
[[package]]
name = "js-sys"
version = "0.3.55"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7cc9ffccd38c451a86bf13657df244e9c3f37493cce8e5e21e940963777acc84"
dependencies = [
"wasm-bindgen",
]
[[package]]
name = "json-rpc"
version = "0.1.0"
dependencies = [
"enso-prelude",
"enso-profiler",
"enso-profiler-data",
"enso-shapely",
"enso-web",
"failure",
"futures 0.3.21",
"serde",
"serde_json",
"shrinkwraprs 0.3.0",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "jsonwebtoken"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
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"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
checksum = "cc9051c17f81bae79440afa041b3a278e1de71bfb96d32454b477fd4703ccb6f"
2022-05-23 05:16:04 +03:00
dependencies = [
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
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",
]
[[package]]
name = "keccak"
version = "0.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f9b7d56ba4a8344d6be9729995e6b06f928af29998cdf79fe390cbf6b1fee838"
[[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 = [
"log 0.4.17",
]
[[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"
[[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 = "lexpr"
version = "0.2.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ceee0b80e0043f17bf81130471e1b0975179af75fe657af45577d80e2698fe3b"
dependencies = [
"itoa 0.4.8",
"lexpr-macros",
"proc-macro-hack",
"ryu",
]
[[package]]
name = "lexpr-macros"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cd627fb38e19c00d8d068618259205f7a91c91aeade5c15bc35dbca037bb1c35"
dependencies = [
"proc-macro-hack",
"proc-macro2",
"quote",
]
[[package]]
name = "libc"
2022-05-23 05:16:04 +03:00
version = "0.2.126"
source = "registry+https://github.com/rust-lang/crates.io-index"
2022-05-23 05:16:04 +03:00
checksum = "349d5a591cd28b49e1d1037471617a32ddcda5731b99419008085f72d5a53836"
[[package]]
name = "libm"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "33a33a362ce288760ec6a508b94caaec573ae7d3bbbd91b87aa0bad4456839db"
[[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"
dependencies = [
2022-05-23 05:16:04 +03:00
"autocfg 1.1.0",
"scopeguard",
]
[[package]]
name = "log"
version = "0.3.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e19e8d5c34a3e0e2223db8e060f9e8264aeeb5c5fc64a4ee9965c062211c024b"
dependencies = [
"log 0.4.17",
]
[[package]]
name = "log"
version = "0.4.17"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "abb12e687cfb44aa40f41fc3978ef76448f9b6038cad6aef4259d3c095a2382e"
dependencies = [
"cfg-if 1.0.0",
"value-bag",
]
[[package]]
name = "logstat"
version = "0.1.0"
dependencies = [
"clap 3.1.18",
"enso-prelude",
"lazy_static",
"regex",
"time 0.3.9",
"tokio 1.19.2",
"tokio-stream",
]
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",
]
[[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"
[[package]]
name = "matrixmultiply"
version = "0.2.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "916806ba0031cd542105d916a97c8572e1fa6dd79c9c51e7eb43a09ec2dd84c1"
dependencies = [
"rawpointer",
]
[[package]]
name = "matrixmultiply"
version = "0.3.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "add85d4dd35074e6fedc608f8c8f513a3548619a9024b751949ef0e8e45a4d84"
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 = "md-5"
version = "0.10.1"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "658646b21e0b72f7866c7038ab086d3d5e1cd6271f060fd37defb241949d0582"
dependencies = [
"digest 0.10.3",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "memchr"
version = "2.5.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2dffe52ecf27772e601905b7522cb4ef790d2cc203488bbd0e2fe85fcb74566d"
[[package]]
name = "memoffset"
version = "0.6.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5aa361d4faea93603064a027415f07bd8e1d5c88c9fbf68bf56a285428fd79ce"
dependencies = [
"autocfg 1.1.0",
]
[[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"
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"
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"
[[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"
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"
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",
"log 0.4.17",
"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",
]
[[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",
"syn",
]
[[package]]
name = "multi-map"
version = "1.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bba551d6d795f74a01767577ea8339560bf0a65354e0417b7e915ed608443d46"
[[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 0.2.2",
"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",
"matrixmultiply 0.3.2",
"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.7",
2022-05-23 05:16:04 +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"
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"
dependencies = [
"lazy_static",
"libc",
"log 0.4.17",
"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"
version = "0.24.1"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
]
[[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",
]
[[package]]
name = "num"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "43db66d1170d347f9a065114077f7dccb00c1b9478c89384490a3425279a4606"
dependencies = [
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
"num-bigint",
"num-complex 0.4.1",
"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 = [
"autocfg 1.1.0",
"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 = [
"autocfg 1.1.0",
"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"
version = "0.4.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "97fbc387afefefd5e9e39493299f3069e14a140dd34dc19b4c1c1a8fddb6a790"
dependencies = [
"num-traits",
]
[[package]]
name = "num-integer"
version = "0.1.45"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "225d3389fb3509a24c93f5c29eb6bde2586b98d9f016636dff58d7c6f7569cd9"
dependencies = [
"autocfg 1.1.0",
"num-traits",
]
[[package]]
name = "num-iter"
version = "0.1.43"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7d03e6c028c5dc5cac6e2dec0efda81fc887605bb3d884578bb6d6bf7514e252"
dependencies = [
"autocfg 1.1.0",
"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 = [
"autocfg 1.1.0",
"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 = [
"autocfg 1.1.0",
"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 = [
"autocfg 1.1.0",
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
"num-bigint",
"num-integer",
"num-traits",
]
[[package]]
name = "num-traits"
version = "0.2.15"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "578ede34cf02f8924ab9447f50c28075b4d3e5b269972345e7e0372b38c6cdcd"
dependencies = [
"autocfg 1.1.0",
"libm",
]
[[package]]
name = "num_cpus"
version = "1.13.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "19e64526ebdee182341572e50e9ad03965aa510cd94427a4549448f285e957a1"
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"
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"
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"
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"
dependencies = [
"proc-macro-crate",
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"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"
[[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"
source = "registry+https://github.com/rust-lang/crates.io-index"
2022-05-23 05:16:04 +03:00
checksum = "e42c982f2d955fac81dd7e1d0e1426a7d702acd9c98d19ab01083a6a0328c424"
dependencies = [
"memchr",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "octocrab"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
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",
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
"secrecy",
2022-05-23 05:16:04 +03:00
"serde",
"serde_json",
"serde_path_to_error",
"snafu",
2022-05-23 05:16:04 +03:00
"url 2.2.2",
]
[[package]]
name = "once_cell"
version = "1.12.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7709cef83f0c1f58f666e746a08b21e0085f7440fa6a29cc194d68aac97a4225"
[[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"
[[package]]
name = "opaque-debug"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "624a8340c38c1b80fd549087862da4ba43e08858af025b236e509b6649fc13d5"
[[package]]
name = "openssl"
version = "0.10.40"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "fb81a6430ac911acb25fe5ac8f1d2af1b4ea8a4fdfda0f1ee4292af2e2d8eb0e"
dependencies = [
"bitflags",
"cfg-if 1.0.0",
"foreign-types",
"libc",
"once_cell",
"openssl-macros",
"openssl-sys",
]
[[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",
]
[[package]]
name = "openssl-probe"
version = "0.1.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ff011a302c396a5197692431fc1948019154afc178baf7d8e37367442a4601cf"
[[package]]
name = "openssl-sys"
version = "0.9.73"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9d5fd19fb3e0a8191c1e34935718976a3e70c112ab9a24af6d7cadccd9d90bc0"
dependencies = [
"autocfg 1.1.0",
"cc",
"libc",
"pkg-config",
"vcpkg",
]
2022-06-22 18:39:32 +03:00
[[package]]
name = "ordered-float"
version = "3.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "96bcbab4bfea7a59c2c0fe47211a1ac4e3e96bea6eb446d704f310bc5c732ae2"
dependencies = [
"num-traits",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "os_str_bytes"
version = "6.1.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "21326818e99cfe6ce1e524c2a805c189a99b5ae555a35d19f9a284b427d86afa"
2022-05-23 05:16:04 +03:00
[[package]]
name = "ouroboros"
version = "0.15.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9f31a3b678685b150cba82b702dcdc5e155893f63610cf388d30cd988d4ca2bf"
2022-05-23 05:16:04 +03:00
dependencies = [
"aliasable",
"ouroboros_macro",
"stable_deref_trait",
]
[[package]]
name = "ouroboros_macro"
version = "0.15.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "084fd65d5dd8b3772edccb5ffd1e4b7eba43897ecd0f9401e330e8c542959408"
2022-05-23 05:16:04 +03:00
dependencies = [
"Inflector",
"proc-macro-error",
"proc-macro2",
"quote",
"syn",
]
2022-08-27 01:25:34 +03:00
[[package]]
name = "owned_ttf_parser"
version = "0.15.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "07ef1a404ae479dd6906f4fa2c88b3c94028f1284beb42a47c183a7c27ee9a3e"
dependencies = [
"ttf-parser",
]
[[package]]
name = "parking"
version = "2.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "427c3892f9e783d91cc128285287e70a59e206ca452770ece88a76f7a3eddd72"
[[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",
"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",
]
[[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",
]
[[package]]
name = "parser"
version = "0.1.0"
dependencies = [
"ast",
"bytes 0.5.6",
"console_error_panic_hook",
"enso-build-utilities",
"enso-data-structures",
"enso-prelude",
"enso-profiler",
"enso-text",
"failure",
"futures 0.3.21",
"js-sys",
"matches",
2022-05-23 05:16:04 +03:00
"reqwest 0.10.10",
"serde",
"serde_json",
"shrinkwraprs 0.2.3",
2022-05-23 05:16:04 +03:00
"tokio 0.2.25",
"uuid 0.8.2",
"wasm-bindgen",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
"websocket",
]
[[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",
]
[[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"
version = "1.0.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0c520e05135d6e763148b6426a837e239041653ba7becd2e538c076c738025fc"
[[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",
]
[[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"
[[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"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
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"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
checksum = "e9a3b09a20e374558580a4914d3b7d89bd61b954a5a5e1dcbea98753addb1947"
2022-05-23 05:16:04 +03:00
dependencies = [
"base64 0.13.0",
]
[[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"
version = "1.0.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "58ad3879ad3baf4e44784bc6a718a8698867bb991f8ce24d1bcbe2cfb4c3a75e"
dependencies = [
"pin-project-internal",
]
[[package]]
name = "pin-project-internal"
version = "1.0.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "744b6f092ba29c3650faf274db506afd39944f48420f6c86b17cfe0ee1cb36bb"
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"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"
version = "0.2.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e0a7ae3ac2f1173085d398531c705756c94a4c56843785df85a60c1a0afac116"
[[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"
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"
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",
]
[[package]]
name = "plotters"
version = "0.3.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "32a3fd9ec30b9749ce28cd91f255d569591cdf937fe280c312143e3c4bad6f2a"
dependencies = [
"num-traits",
"plotters-backend",
"plotters-svg",
"wasm-bindgen",
"web-sys",
]
[[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",
"log 0.4.17",
"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"
[[package]]
name = "ppv-lite86"
version = "0.2.16"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "eb9f9e6e233e5c4a35559a617bf40a4ec447db2e84c20b55a6f83167b7e57872"
[[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"
version = "1.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "da1c2388b1513e1b605fcec39a95e0a9e8ef088f71443ef37099fa9ae6673fcb"
[[package]]
name = "predicates-tree"
version = "1.0.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4d86de6de25020a36c6d3643a86d9a6a9f552107c0559c60ea03551b5e16c032"
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",
]
[[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"
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"
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",
]
[[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"
version = "1.0.40"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "dd96a1e8ed2596c337f8eae5f24924ec83f5ad5ab21ea8e455d3566c69fbcaf7"
dependencies = [
2022-05-23 05:16:04 +03:00
"unicode-ident",
]
[[package]]
name = "prost"
version = "0.10.4"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
]
[[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"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
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",
]
[[package]]
name = "quote"
version = "1.0.20"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3bcdf212e9776fbcb2d23ab029360416bb1706b1aea2d1a5ba002727cbcab804"
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
]
[[package]]
name = "rand"
version = "0.6.5"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6d71dacdc3c88c1fde3885a3be3fbab9f35724e6ce99467f7d9c5026132184ca"
dependencies = [
"autocfg 0.1.8",
"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",
]
[[package]]
name = "rand_chacha"
version = "0.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "556d3a1ca6600bfcbab7c7c91ccb085ac7fbbcd70e008a98742e7847f4f7bcef"
dependencies = [
"autocfg 0.1.8",
"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",
]
[[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.7",
2022-05-23 05:16:04 +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_distr"
version = "0.4.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "32cb0b9bc82b0a0876c2dd994a7e7a2683d3e7390ca40e6886785ef0c7e3ee31"
dependencies = [
"num-traits",
"rand 0.8.5",
]
[[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 = [
"autocfg 0.1.8",
"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"
source = "registry+https://github.com/rust-lang/crates.io-index"
2022-05-23 05:16:04 +03:00
checksum = "bd99e5772ead8baa5215278c9b15bf92087709e9c1b2d1f97cdb5a183c933a7d"
dependencies = [
"autocfg 1.1.0",
"crossbeam-deque",
"either",
"rayon-core",
]
[[package]]
name = "rayon-core"
2022-05-23 05:16:04 +03:00
version = "1.9.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
2022-05-23 05:16:04 +03:00
checksum = "258bcdb5ac6dad48491bb2992db6b7cf74878b0384908af124823d118c99683f"
dependencies = [
"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",
"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"
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"
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.7",
2022-05-23 05:16:04 +03:00
"redox_syscall 0.2.13",
"thiserror",
]
[[package]]
name = "regex"
version = "1.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4c4eb3267174b8c6c2f654116623910a0fef09c4753f8dd83db29c48a0df988b"
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",
]
[[package]]
name = "regex-syntax"
version = "0.6.27"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a3f87b73ce11b1619a3c6332f45341e0047173771e8b8b73f87bfeefb7b56244"
[[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"
version = "0.10.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0718f81a8e14c4dbb3b34cf23dc6aaf9ab8a0dfec160c534b3dbca1aaa21f47c"
dependencies = [
"base64 0.13.0",
"bytes 0.5.6",
"encoding_rs",
"futures-core",
"futures-util",
"http",
2022-05-23 05:16:04 +03:00
"http-body 0.3.1",
"hyper 0.13.10",
"hyper-tls",
"ipnet",
"js-sys",
"lazy_static",
"log 0.4.17",
"mime 0.3.16",
"mime_guess",
"native-tls",
"percent-encoding 2.1.0",
"pin-project-lite 0.2.9",
"serde",
2022-08-27 01:25:34 +03:00
"serde_json",
"serde_urlencoded",
2022-05-23 05:16:04 +03:00
"tokio 0.2.25",
"tokio-tls 0.3.1",
"url 2.2.2",
"wasm-bindgen",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-futures",
"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",
]
[[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 = [
"semver 1.0.9",
]
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",
]
[[package]]
name = "rustversion"
version = "1.0.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f2cc38e8fa666e2de3c4aba7edeb5ffc5246c1c2ed0e3d17e560aeeba736b23f"
[[package]]
name = "ryu"
2022-05-23 05:16:04 +03:00
version = "1.0.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
2022-05-23 05:16:04 +03:00
checksum = "f3f6f92acf49d1b98f7a81226834412ada05458b7364277387724a237f062695"
[[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"
checksum = "93fc1dc3aaa9bfed95e02e6eadabb4baf7e3078b0bd1b4d7b6b0b68378900502"
dependencies = [
"winapi-util",
]
2021-01-25 17:41:20 +03:00
[[package]]
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 = [
"lazy_static",
2022-05-23 05:16:04 +03:00
"windows-sys",
2021-01-25 17:41:20 +03:00
]
[[package]]
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",
]
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
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",
]
[[package]]
name = "security-framework"
version = "2.6.1"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2dc14f172faf8a0194a3aded622712b0de276821addc574fa54fc0a1167e10dc"
2021-01-25 17:41:20 +03:00
dependencies = [
"bitflags",
"core-foundation",
"core-foundation-sys",
"libc",
"security-framework-sys",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "security-framework-sys"
version = "2.6.1"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0160a13a177a45bfb43ce71c01580998474f556ad854dcbca936dd2841a5c556"
2021-01-25 17:41:20 +03:00
dependencies = [
"core-foundation-sys",
"libc",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "segment-tree"
version = "2.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3f7dbd0d32cabaa6c7c3286d756268247538d613b621227bfe59237d7bbb271a"
2021-01-25 17:41:20 +03:00
[[package]]
name = "semver"
version = "0.9.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1d7eb9ef2c18661902cc47e535f9bc51b78acd254da71d375c2f6720d9a40403"
2021-01-25 17:41:20 +03:00
dependencies = [
"semver-parser",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "semver"
version = "1.0.9"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8cb243bdfdb5936c8dc3c45762a19d12ab4550cdc753bc247637d4ec35a040fd"
2021-01-25 17:41:20 +03:00
dependencies = [
"serde",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "388a1df253eca08550bef6c72392cfe7c30914bf41df5269b68cbd6ff8f570a3"
2021-01-25 17:41:20 +03:00
[[package]]
name = "serde"
version = "1.0.144"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0f747710de3dcd43b88c9168773254e809d8ddbdf9653b84e2554ab219f17860"
2021-01-25 17:41:20 +03:00
dependencies = [
"serde_derive",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "2bef2ebfde456fb76bbcf9f59315333decc4fda0b2b44b420243c11e0f5ec1f5"
2021-01-25 17:41:20 +03:00
dependencies = [
"half",
"serde",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "serde_derive"
version = "1.0.144"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "94ed3a816fb1d101812f83e789f888322c34e291f894f19590dc310963e87a00"
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "serde_json"
version = "1.0.81"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9b7ce2b32a1aed03c558dc61a5cd328f15aff2dbc17daad8fb8af04d2100e15c"
2021-01-25 17:41:20 +03:00
dependencies = [
2022-05-23 05:16:04 +03:00
"itoa 1.0.2",
"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]]
name = "serde_urlencoded"
version = "0.7.1"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d3491c14715ca2294c4d6a88f15e84739788c1d030eed8c110436aafdaa2f3fd"
2021-01-25 17:41:20 +03:00
dependencies = [
"form_urlencoded",
2022-05-23 05:16:04 +03:00
"itoa 1.0.2",
"ryu",
"serde",
2021-01-25 17:41:20 +03:00
]
[[package]]
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",
"serde",
"yaml-rust",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "serde_yaml"
version = "0.9.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7a09f551ccc8210268ef848f0bab37b306e87b85b2e017b899e7fb815f5aed62"
dependencies = [
"indexmap",
"itoa 1.0.2",
"ryu",
"serde",
"unsafe-libyaml",
]
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]]
name = "sha1"
version = "0.6.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c1da05c97445caa12d05e848c4a4fcbbea29e748ac28f7e80e9b010392063770"
dependencies = [
"sha1_smol",
]
[[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",
]
[[package]]
name = "sha1_smol"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ae1a47186c03a32177042e55dbc5fd5aee900b8e0069a8d70fba96a9375cd012"
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",
]
[[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"
checksum = "dd26bc0e7a2e3a7c959bc494caf58b72ee0c71d67704e9520f736ca7e4853ecf"
2021-01-25 17:41:20 +03:00
dependencies = [
2022-05-23 05:16:04 +03:00
"block-buffer 0.7.3",
"byte-tools",
2022-05-23 05:16:04 +03:00
"digest 0.8.1",
"keccak",
"opaque-debug 0.2.3",
2021-01-25 17:41: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]]
name = "shrinkwraprs"
version = "0.2.3"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "83695fde96cbe9e08f0e4eb96b1b56fdbd44f2098ee27462dda964c7745fddc7"
dependencies = [
"bitflags",
"itertools 0.8.2",
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
]
2021-01-25 17:41:20 +03:00
[[package]]
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",
"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",
]
[[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"
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]]
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",
"paste 1.0.7",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "simple_asn1"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
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"
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
checksum = "4a762b1c38b9b990c694b9c2f8abe3372ce6a9ceaae6bca39cfc46e054f45745"
2022-05-23 05:16:04 +03:00
dependencies = [
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
"num-bigint",
2022-05-23 05:16:04 +03:00
"num-traits",
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
"thiserror",
"time 0.3.9",
2022-05-23 05:16:04 +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"
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"
[[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"
version = "1.8.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f2dd574626839106c320a323308629dcb1acfc96e32a8cba364ddc61ac23ee83"
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",
"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",
]
[[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]]
name = "socket2"
version = "0.4.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "66d72b759436ae32898a2af0a14218dbf55efde3feeb170eb623637db85ee1e0"
dependencies = [
"libc",
"winapi 0.3.9",
]
[[package]]
name = "sourcemap"
version = "6.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a2ca89636b276071e7276488131f531dbf43ad1c19bc4bd5a04f6a0ce1ddc138"
dependencies = [
"base64 0.11.0",
"if_chain",
"lazy_static",
"regex",
"rustc_version 0.2.3",
"serde",
"serde_json",
"url 2.2.2",
]
[[package]]
name = "span-tree"
version = "0.1.0"
dependencies = [
"ast",
"enso-data-structures",
"enso-prelude",
"enso-profiler",
"enso-text",
"failure",
"parser",
2022-02-11 15:19:02 +03:00
"wasm-bindgen-test",
]
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"
[[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 = [
"strum_macros",
2022-05-23 05:16:04 +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",
"proc-macro2",
"quote",
"rustversion",
"syn",
]
[[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"
[[package]]
name = "syn"
version = "1.0.98"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c50aef8a904de4c23c788f104b7dddc7d6f79c647c7c8ce4cc8f73eb0ca773dd"
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
2022-05-23 05:16:04 +03:00
"unicode-ident",
]
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"
[[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",
"syn",
2022-02-11 15:19:02 +03:00
"unicode-xid",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "sysinfo"
version = "0.23.13"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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 = "sysinfo"
version = "0.25.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "71eb43e528fdc239f08717ec2a378fdb017dddbc3412de15fff527554591a66c"
dependencies = [
"cfg-if 1.0.0",
"core-foundation-sys",
"libc",
"ntapi",
"once_cell",
"rayon",
"winapi 0.3.9",
]
2022-05-23 05:16:04 +03:00
[[package]]
name = "tar"
version = "0.4.38"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4b55807c0344e1e6c04d7c965f5289c39a8d94ae23ed5c0b57aabac549f871c6"
dependencies = [
"filetime",
"libc",
"xattr",
]
[[package]]
name = "tempfile"
version = "3.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5cdb1ef4eaeeaddc8fbd371e5017057064af0911902ef36b39801f67cc6d79e4"
dependencies = [
"cfg-if 1.0.0",
"fastrand",
"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",
"winapi 0.3.9",
]
[[package]]
name = "termtree"
version = "0.2.4"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "507e9898683b6c43a9aa55b64259b721b52ba226e0f3779137e50ad114a4c90b"
[[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 = [
"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]]
name = "thiserror"
version = "1.0.31"
2021-05-14 15:08:39 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bd829fe32373d27f76265620b5309d0340cb8550f523c1dda251d6298069069a"
dependencies = [
"thiserror-impl",
]
2021-05-14 15:08:39 +03:00
2021-01-25 17:41:20 +03:00
[[package]]
name = "thiserror-impl"
version = "1.0.31"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0396bc89e626244658bef819e22d0cc459e795a5ebe878e6ec336d1674a8d79a"
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
]
2021-01-25 17:41: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]]
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 = [
"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",
"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 = [
"itoa 1.0.2",
2022-05-23 05:16:04 +03:00
"libc",
"num_threads",
Bumped the build script (#3489) * The bash entry point was renamed `run.sh` -> `run`. Thanks to that `./run` works both on Linux and Windows with PowerShell (sadly not on CMD). * Everyone's favorite checks for WASM size and program versions are back. These can be disabled through `--wasm-size-limit=0` and `--skip-version-check` respectively. WASM size limit is stored in `build-config.yaml`. * Improved diagnostics for case when downloaded CI run artifact archive cannot be extracted. * Added GH API authentication to the build script calls on CI. This should fix the macOS build failures that were occurring from time to time. (Actually they were due to runner being GitHub-hosted, not really an OS-specific issue by itself.) * If the GH API Personal Access Token is provided, it will be validated. Later on it is difficult to say, whether fail was caused by wrong PAT or other issue. * Renamed `clean` to `git-clean` as per suggestion to reduce risk of user accidently deleting unstaged work. * Whitelisting dependabot from changelog checks, so PRs created by it are mergeable. * Fixing issue where wasm-pack-action (third party) randomly failed to recognize the latest version of wasm-pack (macOS runners), leading to failed builds. * Build logs can be filtered using `ENSO_BUILD_LOG` environment variable. See https://docs.rs/tracing-subscriber/0.3.11/tracing_subscriber/struct.EnvFilter.html#directives for the supported syntax. * Improve help for ci-run source, to make clear that PAT token is required and what scope is expected there. Also, JS parts were updated with some cleanups and fixes following the changes made when introducing the build script.
2022-06-01 14:44:40 +03:00
"quickcheck",
"time-macros",
2022-05-23 05:16:04 +03:00
]
[[package]]
name = "time-macros"
version = "0.2.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "42657b1a6f4d817cda8e7a0ace261fe0cc946cf3a80314390b22cc61ae080792"
[[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"
version = "1.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "87cc5ceb3875bb20c2890005a4e226a4651264a5c75edb2421b52861a0a0cb50"
dependencies = [
"tinyvec_macros",
2021-01-25 17:41:20 +03:00
]
2021-10-30 16:04:07 +03:00
[[package]]
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"
checksum = "cda74da7e1a664f795bb1f8a87ec406fb89a02522cf6e50620d016add6dbbf5c"
2021-10-30 16:04:07 +03:00
2021-01-25 17:41:20 +03:00
[[package]]
name = "tokio"
version = "0.2.25"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
"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-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "25b2998660ba0e70d18684de5d06b70b70a3a747469af9dea7618cc59e75976b"
2021-01-25 17:41:20 +03:00
dependencies = [
"bytes 0.4.12",
"futures 0.1.31",
"tokio-io",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "fb2d1b8f4548dbf5e1f7818512e9c406860678f29c300cdf0ebac72d1a3a1671"
dependencies = [
"crossbeam-utils 0.7.2",
"futures 0.1.31",
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "57fc868aae093479e3131e3d165c93b1c7474109d13c90ec0dda2a1bbfff0674"
2021-01-25 17:41:20 +03:00
dependencies = [
"bytes 0.4.12",
"futures 0.1.31",
"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]]
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"
checksum = "e44da00bfc73a25f814cd8d7e57a68a5c31b74b3152a0a1d1f590c97ed06265a"
2021-01-25 17:41:20 +03:00
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"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",
]
[[package]]
name = "tokio-native-tls"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f7d995660bd2b7f8c1568414c1126076c13fbb725c40112dc0120b78eb9b717b"
dependencies = [
"native-tls",
"tokio 1.19.2",
]
2021-01-25 17:41:20 +03:00
[[package]]
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"
checksum = "09bc590ec4ba8ba87652da2068d150dcada2cfa2e07faae270a5e0409aa51351"
2021-01-25 17:41:20 +03:00
dependencies = [
"crossbeam-utils 0.7.2",
"futures 0.1.31",
"lazy_static",
"log 0.4.17",
2022-05-23 05:16:04 +03:00
"mio 0.6.23",
"num_cpus",
2022-05-23 05:16:04 +03:00
"parking_lot 0.9.0",
"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.9"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "df54d54117d6fdc4e4fea40fe1e4e566b3505700e148a6827e59b34b0d2600d9"
2022-05-23 05:16:04 +03:00
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]]
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"
checksum = "edfe50152bc8164fcc456dab7891fa9bf8beaf01c5ee7e1dd43a397c3cf87dee"
2021-01-25 17:41:20 +03:00
dependencies = [
"fnv",
"futures 0.1.31",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "98df18ed66e3b72e742f185882a9e201892407957e45fbff8da17ae7a7c51f72"
2021-01-25 17:41:20 +03:00
dependencies = [
"bytes 0.4.12",
"futures 0.1.31",
"iovec",
2022-05-23 05:16:04 +03:00
"mio 0.6.23",
"tokio-io",
"tokio-reactor",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "354b8cd83825b3c20217a9dc174d6a0c67441a2fae5c41bcb1ea6679f6ae0f7c"
2021-01-25 17:41:20 +03:00
dependencies = [
"futures 0.1.31",
"native-tls",
"tokio-io",
2021-10-30 16:04:07 +03:00
]
[[package]]
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"
checksum = "9a70f4fcd7b3b24fb194f837560168208f669ca8cb70d0c4b862944452396343"
2021-10-30 16:04:07 +03:00
dependencies = [
"native-tls",
2022-05-23 05:16:04 +03:00
"tokio 0.2.25",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "be8242891f2b6cbef26a2d7e8605133c2c554cd35b3e4948ea892d6d68436499"
dependencies = [
"bytes 0.5.6",
"futures-core",
"futures-sink",
"log 0.4.17",
"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",
"futures-io",
2022-05-23 05:16:04 +03:00
"futures-sink",
"futures-util",
2022-05-23 05:16:04 +03:00
"pin-project-lite 0.2.9",
"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-01-25 17:41:20 +03:00
[[package]]
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"
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]]
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"
checksum = "360dfd1d6d30e05fda32ace2c8c70e9c0a9da713275777f5a4dbb8a1893930c6"
2021-01-25 17:41:20 +03:00
[[package]]
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 = [
"cfg-if 1.0.0",
"log 0.4.17",
"pin-project-lite 0.2.9",
"tracing-attributes",
"tracing-core",
2021-01-25 17:41: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]]
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 = [
"lazy_static",
"valuable",
2021-01-25 17:41:20 +03:00
]
[[package]]
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"
checksum = "97d095ae15e245a057c8e8451bab9b3ee1e1f68e9ba2b4fbc18d0ac5237835f2"
2021-01-25 17:41:20 +03:00
dependencies = [
"pin-project",
"tracing",
2021-01-25 17:41: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",
"sharded-slab",
"smallvec 1.8.0",
"thread_local",
2022-05-23 05:16:04 +03:00
"tracing",
"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]]
name = "traitobject"
version = "0.1.0"
2021-05-14 15:08:39 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "efd1f82c56340fdf16f2a953d7bda4f8fdffba13d93b00844c25572110b26079"
2021-05-14 15:08:39 +03:00
[[package]]
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"
checksum = "59547bce71d9c38b83d9c0e92b6066c4253371f15005def0c30d9657f50c7642"
2021-05-14 15:08:39 +03:00
2022-08-27 01:25:34 +03:00
[[package]]
name = "ttf-parser"
version = "0.15.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7b3e06c9b9d80ed6b745c7159c40b311ad2916abb34a49e9be2653b90db0d8dd"
2021-01-25 17:41:20 +03:00
[[package]]
name = "typeable"
version = "0.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1410f6f91f21d1612654e7cc69193b0334f909dcf2c790c4826254fbb86f8887"
[[package]]
name = "typenum"
version = "1.15.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "dcf81ac59edc17cc8697ff311e8f5ef2d99fcbd9817b34cec66f90b6c3dfd987"
[[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"
checksum = "7f4765f83163b74f957c797ad9253caf97f103fb064d3999aea9568d09fc8a33"
2021-01-25 17:41:20 +03:00
dependencies = [
"version_check 0.1.5",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "unicase"
version = "2.6.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "50f37be617794602aabbeee0be4f259dc1778fabe05e2d67ee8f79326d5cb4f6"
2021-01-25 17:41:20 +03:00
dependencies = [
"version_check 0.9.4",
2021-01-25 17:41:20 +03:00
]
[[package]]
name = "unicode-bidi"
version = "0.3.8"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "099b7128301d285f79ddd55b9a83d5e6b9e97c92e0ea0daebee7263e932de992"
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"
[[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"
checksum = "d54590932941a9e9266f0832deed84ebe1bf2e4c9e4a3554d393d18f5e854bf9"
dependencies = [
"tinyvec",
]
2021-01-25 17:41:20 +03:00
[[package]]
name = "unicode-segmentation"
version = "1.9.0"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7e8820f5d777f6224dc4be3632222971ac30164d4a258d595640799554ebfd99"
2021-01-25 17:41:20 +03:00
[[package]]
name = "unicode-width"
version = "0.1.9"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3ed742d4ea2bd1176e236172c8429aaf54486e7ac098db29ffe6529e0ce50973"
2021-01-25 17:41:20 +03:00
[[package]]
name = "unicode-xid"
version = "0.2.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "957e51f3646910546462e67d5f7599b9e4fb8acdd304b087a6494730f9eebf04"
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 = "unsafe-libyaml"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "931179334a56395bcf64ba5e0ff56781381c1a5832178280c7d7f91d1679aeb0"
2022-05-23 05:16:04 +03:00
[[package]]
name = "untrusted"
version = "0.7.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a156c684c91ea7d62626509bce3cb4e1d9ed5c4d978f7b4352658f96a4c26b4a"
[[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"
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-01-25 17:41:20 +03:00
2022-05-23 05:16:04 +03:00
[[package]]
name = "urlencoding"
version = "2.1.0"
2022-05-23 05:16:04 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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"
version = "0.8.2"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "bc5cf98d8186244414c848017f0e2676b3fcb46807f6668a97dfe67359a3c4b7"
2021-01-25 17:41:20 +03:00
dependencies = [
"getrandom 0.2.7",
2021-01-25 17:41:20 +03:00
"serde",
"sha1 0.6.1",
]
[[package]]
name = "uuid"
version = "1.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "dd6469f4314d5f1ffec476e05f17cc9a78bc7a27a6a857842170bdf8d6f98d2f"
dependencies = [
"getrandom 0.2.7",
"serde",
]
[[package]]
name = "valuable"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "830b7e5d4d90034032940e4ace0d9a9a057e7a45cd94e6c007832e39edb82f6d"
[[package]]
name = "value-bag"
version = "1.0.0-alpha.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2209b78d1249f7e6f3293657c9779fe31ced465df091bbd433a1cf88e916ec55"
dependencies = [
"ctor",
"version_check 0.9.4",
2021-01-25 17:41:20 +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"
[[package]]
name = "version_check"
version = "0.9.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "49874b5167b65d7193b8aba1567f5c7d93d001cafc34600cee003eda787e483f"
2022-08-27 01:25:34 +03:00
[[package]]
name = "virtue"
version = "0.0.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "757cfbfe0d17ee6f22fe97e536d463047d451b47cf9d11e2b7d1398b0ef274dd"
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"
[[package]]
name = "waker-fn"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9d5b2c62b4012a3e1eca5a7e077d13b3bf498c4073e33ccd58626607748ceeca"
2021-01-25 17:41:20 +03:00
[[package]]
name = "walkdir"
version = "2.3.2"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "808cf2735cd4b6866113f648b791c6adc5714537bc222d9347bb203386ffda56"
2021-01-25 17:41:20 +03:00
dependencies = [
"same-file",
"winapi 0.3.9",
2021-01-25 17:41:20 +03:00
"winapi-util",
]
[[package]]
name = "want"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1ce8a968cb1cd110d136ff8b819a556d6fb6d919363c61534f6860c7eb172ba0"
dependencies = [
"log 0.4.17",
"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"
[[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"
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"
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"
version = "0.2.78"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "632f73e236b219150ea279196e54e610f5dbafa5d61786303d4da54f84e47fce"
2021-01-25 17:41:20 +03:00
dependencies = [
"cfg-if 1.0.0",
"serde",
"serde_json",
2021-01-25 17:41:20 +03:00
"wasm-bindgen-macro",
]
[[package]]
name = "wasm-bindgen-backend"
version = "0.2.78"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a317bf8f9fba2476b4b2c85ef4c4af8ff39c3c7f0cdfeed4f82c34a880aa837b"
2021-01-25 17:41:20 +03:00
dependencies = [
"bumpalo",
"lazy_static",
"log 0.4.17",
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
2021-01-25 17:41:20 +03:00
"wasm-bindgen-shared",
]
[[package]]
name = "wasm-bindgen-futures"
version = "0.4.28"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8e8d7523cb1f2a4c96c1317ca690031b714a51cc14e05f712446691f413f5d39"
dependencies = [
"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"
version = "0.2.78"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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"
version = "0.2.78"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7803e0eea25835f8abdc585cd3021b3deb11543c6fe226dcd30b228857c5c5ab"
2021-01-25 17:41:20 +03:00
dependencies = [
2022-02-11 15:19:02 +03:00
"proc-macro2",
"quote",
"syn",
2021-01-25 17:41:20 +03:00
"wasm-bindgen-backend",
"wasm-bindgen-shared",
]
[[package]]
name = "wasm-bindgen-shared"
version = "0.2.78"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0237232789cf037d5480773fe568aac745bfe2afbc11a863e97901780a6b47cc"
2021-01-25 17:41:20 +03:00
[[package]]
name = "wasm-bindgen-test"
version = "0.3.28"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "96f1aa7971fdf61ef0f353602102dbea75a56e225ed036c1e3740564b91e6b7e"
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
]
[[package]]
name = "wasm-bindgen-test-macro"
version = "0.3.28"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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"
version = "0.3.2"
2021-10-30 16:04:07 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "323f4da9523e9a669e1eaf9c6e763892769b1d38c623913647bfdc1532fe4549"
2021-10-30 16:04:07 +03:00
2021-01-25 17:41:20 +03:00
[[package]]
name = "web-sys"
version = "0.3.55"
2021-01-25 17:41:20 +03:00
source = "registry+https://github.com/rust-lang/crates.io-index"
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",
]
[[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",
"sha1 0.6.1",
"tokio-codec",
"tokio-io",
"tokio-reactor",
"tokio-tcp",
"tokio-tls 0.2.1",
"unicase 1.4.2",
"url 1.7.2",
]
[[package]]
name = "websocket-codec"
version = "0.5.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "72154d7f42457a99b2832ff093a22a6b303d88c6fe87ca975515cc6c7bc8d21d"
dependencies = [
"base64 0.13.0",
"byteorder",
"bytes 1.1.0",
"httparse",
"rand 0.8.5",
"sha1 0.6.1",
"tokio-util 0.7.2",
]
[[package]]
name = "websocket-lite"
version = "0.5.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "44a2fea74fd5c7e2720dfd619bf029b46acef012cc619793d6d76d29c0ba8c14"
dependencies = [
"base64 0.13.0",
"bytes 1.1.0",
"futures 0.3.21",
"native-tls",
"rand 0.8.5",
"tokio 1.19.2",
"tokio-native-tls",
"tokio-util 0.7.2",
"url 2.2.2",
"websocket-codec",
]
[[package]]
name = "welcome-screen"
version = "0.1.0"
dependencies = [
"enso-frp",
"ensogl",
"wasm-bindgen",
"web-sys",
]
[[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",
]
[[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",
]
[[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 = [
"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"
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"
[[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
]
[[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",
]
[[package]]
name = "wstest"
version = "0.1.0"
dependencies = [
"base64 0.13.0",
"clap 3.1.18",
"either",
"enso-prelude",
"futures 0.3.21",
"regex",
"time 0.3.9",
"tokio 1.19.2",
"tokio-stream",
"url 2.2.2",
"websocket-lite",
]
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",
]
[[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"
[[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"
[[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",
]
[[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",
]
[[package]]
name = "zip-extensions"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9adcf027b355870f62cabaed021f9028231d2d84cad6e30a7abdaa4dc0390edd"
dependencies = [
"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",
]