enso/Cargo.toml

54 lines
1.3 KiB
TOML
Raw Normal View History

[workspace]
2022-02-11 15:19:02 +03:00
# Listing only the "root" crates of each app/library. All path dependencies are included in the workspace automatically.
# If you want to add sub crate (like `app/gui/config` or `lib/rust/ensogl/example`), just add it as a path dependency
# where plausible.
members = [
"app/gui",
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
"app/gui/enso-profiler-enso-data",
2022-03-10 06:47:00 +03:00
"build/enso-formatter",
"build/rust-scripts",
2022-02-11 15:19:02 +03:00
"lib/rust/*",
"lib/rust/parser/src/syntax/tree/visitor",
"lib/rust/parser/src/syntax/tree/builder",
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
"lib/rust/profiler/data",
2022-02-11 15:19:02 +03:00
"integration-test"
]
2022-02-11 15:19:02 +03:00
# The default memebers are those we want to check and test by default.
default-members = ["app/gui", "lib/rust/*"]
# We are using a version with extended functionality. The changes have been PR'd upstream:
# https://github.com/rustwasm/console_error_panic_hook/pull/24
# Remove this patch when the issue is resolved.
[patch.crates-io]
console_error_panic_hook = { git = 'https://github.com/enso-org/console_error_panic_hook' }
[profile.dev]
opt-level = 0
lto = false
debug = true
debug-assertions = true
[profile.release]
opt-level = 3
lto = true
debug = false
debug-assertions = false
[profile.bench]
opt-level = 3
lto = true
debug = false
debug-assertions = false
[profile.test]
opt-level = 0
lto = false
debug = true
debug-assertions = true
2022-02-11 15:19:02 +03:00
[profile.integration-test]
inherits = "test"
opt-level = 2