mirror of
https://github.com/enso-org/enso.git
synced 2024-12-25 05:53:28 +03:00
d59710c3cd
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.
46 lines
961 B
TOML
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
|