enso/lib/rust/profiler/data/Cargo.toml

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

[dependencies]
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
enso-prelude = { path = "../../prelude" }
enso-profiler = { path = "../" }

[dev-dependencies]
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			`[package]`
			`name = "enso-profiler-data"`
			`version = "0.1.0"`
			`edition = "2021"`
			`authors = ["Enso Team <contact@enso.org>"]`

			`[dependencies]`
			`serde = { version = "1.0", features = ["derive"] }`
			`serde_json = "1.0"`
Profiling: intervals tool and devtools-file generator (#3359) * Profiling: intervals tool * devtools profile generator * docs * ignore open intervals, because devtools does * intervals tool: show interval counts * Re-add a doc comment. Was accidentally deleted. * Implement review. * DURATION_FLOOR_MS * Rename methods that apply a profile's contents to self * Description of chrome format * Link to profile.json format documentation is design doc * Implement profiling-level switch described in design doc * lint 2022-04-11 16:08:09 +03:00			`enso-prelude = { path = "../../prelude" }`
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			`enso-profiler = { path = "../" }`

			`[dev-dependencies]`
			`futures = "0.3"`