enso/lib/rust/profiler/Cargo.toml

[package]
name = "enso-profiler"
version = "0.1.0"
edition = "2021"
authors = ["Enso Team <contact@enso.org>"]

[dependencies]
futures = "0.3"
serde = { version = "1.0", features = ["derive"] }
serde_json = { version = "1.0.59", features = ["raw_value"] }
wasm-bindgen = { version = "0.2.78", features = ["nightly"] }
enso-profiler-macros = { path = "macros" }
enso-web = { path = "../web" }
Profiling framework: core performance-logging implementation (#3238) * profiling instrumentation * Support native testing with mock impl of `mod js` * Add benchmarks * Wrapper: support methods. * `#[profile]`: work in any context * feature-gate lineno info that breaks IDE * Support async; more docs; add perf analysis * docs & formatting 2022-02-10 20:24:29 +03:00			`[package]`
			`name = "enso-profiler"`
			`version = "0.1.0"`
			`edition = "2021"`
			`authors = ["Enso Team <contact@enso.org>"]`

			`[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			`futures = "0.3"`
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 = { version = "1.0", features = ["derive"] }`
			`serde_json = { version = "1.0.59", features = ["raw_value"] }`
EnsoGL context abstraction (#3293) 2022-03-04 17:13:23 +03:00			`wasm-bindgen = { version = "0.2.78", features = ["nightly"] }`
Profiling framework: core performance-logging implementation (#3238) * profiling instrumentation * Support native testing with mock impl of `mod js` * Add benchmarks * Wrapper: support methods. * `#[profile]`: work in any context * feature-gate lineno info that breaks IDE * Support async; more docs; add perf analysis * docs & formatting 2022-02-10 20:24:29 +03:00			`enso-profiler-macros = { path = "macros" }`
Flame Graph for Profiling Data (#3297) Add an API to create a flame graph from profiling data. Also adds a demo scene showcasing the functionality that generates some profiling data by measuring dummy function calls and rendering a flame graph for the dummy data (see video for the result). Not that the functionality is not yet exposed user-facing in the GUI itself, but only as API and demo scene, therefore [ci no changelog needed] https://user-images.githubusercontent.com/1428930/155118977-ecac0628-777c-48bd-9aa7-30ee6aef1976.mp4 # Important Notes * Change from the initial design: labels are shown on the flame graph instead of as a tooltip. This is because tooltips are currently only implemented in the graph editor and would require some additional refactoring (probably taking the better part of a day). * re-instated the behaviour that logs are shown in the JS console if development mode is active. 2022-03-04 01:23:27 +03:00			`enso-web = { path = "../web" }`