enso/Cargo.toml
Kaz Wesley d59710c3cd
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 16:44:03 +02:00

46 lines
961 B
TOML

[workspace]
# 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",
"app/gui/enso-profiler-enso-data",
"build/enso-formatter",
"build/rust-scripts",
"lib/rust/*",
"lib/rust/profiler/data",
"integration-test"
]
# The default memebers are those we want to check and test by default.
default-members = ["app/gui", "lib/rust/*"]
[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
[profile.integration-test]
inherits = "test"
opt-level = 2