2020-06-16 19:18:11 +03:00
|
|
|
[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.
|
2020-06-16 19:18:11 +03:00
|
|
|
members = [
|
2021-11-16 12:04:56 +03:00
|
|
|
"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",
|
2021-11-16 12:04:56 +03:00
|
|
|
"build/rust-scripts",
|
2022-02-11 15:19:02 +03:00
|
|
|
"lib/rust/*",
|
2022-02-28 12:55:56 +03:00
|
|
|
"lib/rust/profiler/data",
|
2022-02-11 15:19:02 +03:00
|
|
|
"integration-test"
|
2020-06-16 19:18:11 +03:00
|
|
|
]
|
|
|
|
|
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/*"]
|
|
|
|
|
2020-06-16 19:18:11 +03:00
|
|
|
[profile.dev]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 0
|
|
|
|
lto = false
|
|
|
|
debug = true
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = true
|
2020-06-16 19:18:11 +03:00
|
|
|
|
|
|
|
[profile.release]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 3
|
|
|
|
lto = true
|
|
|
|
debug = false
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = false
|
2020-06-16 19:18:11 +03:00
|
|
|
|
|
|
|
[profile.bench]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 3
|
|
|
|
lto = true
|
|
|
|
debug = false
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = false
|
2020-06-16 19:18:11 +03:00
|
|
|
|
|
|
|
[profile.test]
|
2021-11-10 16:36:08 +03:00
|
|
|
opt-level = 0
|
|
|
|
lto = false
|
|
|
|
debug = true
|
2020-08-13 15:23:01 +03:00
|
|
|
debug-assertions = true
|
2022-02-11 15:19:02 +03:00
|
|
|
|
|
|
|
[profile.integration-test]
|
|
|
|
inherits = "test"
|
2022-04-04 18:55:55 +03:00
|
|
|
opt-level = 2
|