diff --git a/Cargo.lock b/Cargo.lock index 33ad8c00262a..3511ffb5391c 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -4445,6 +4445,7 @@ dependencies = [ "re_ui", "re_viewer_context", "rfd", + "unindent", ] [[package]] diff --git a/crates/store/re_chunk_store/src/store.rs b/crates/store/re_chunk_store/src/store.rs index 4b3d36031cff..5fcb9111ec51 100644 --- a/crates/store/re_chunk_store/src/store.rs +++ b/crates/store/re_chunk_store/src/store.rs @@ -43,10 +43,10 @@ pub struct ChunkStoreConfig { /// See also [`ChunkStoreConfig::chunk_max_rows_if_unsorted`]. /// /// This is a multi-dimensional trade-off: - /// * Larger chunks lead to less fixed overhead caused to metadata, indices and such. Good. - /// * Larger chunks lead to slower query execution in unhappy paths. Bad. + /// * Larger chunks lead to less fixed overhead introduced by metadata, indices and such. Good. + /// * Larger chunks lead to slower query execution on some unhappy paths. Bad. /// * Larger chunks lead to slower and slower compaction as chunks grow larger. Bad. - /// * Larger chunks lead to coarser garbage collection. Bad. + /// * Larger chunks lead to coarser garbage collection. Good or bad depending on use case. /// * Larger chunks lead to less precision in e.g. the time panel. Bad. /// /// Empirical testing shows that the space overhead gains rapidly diminish beyond ~1000 rows, @@ -61,10 +61,10 @@ pub struct ChunkStoreConfig { /// See also [`ChunkStoreConfig::chunk_max_rows`]. /// /// This is a multi-dimensional trade-off: - /// * Larger chunks lead to less fixed overhead caused to metadata, indices and such. Good. - /// * Larger chunks lead to slower query execution in unhappy paths. Bad. + /// * Larger chunks lead to less fixed overhead introduced by metadata, indices and such. Good. + /// * Larger chunks lead to slower query execution on some unhappy paths. Bad. /// * Larger chunks lead to slower and slower compaction as chunks grow larger. Bad. - /// * Larger chunks lead to coarser garbage collection. Bad. + /// * Larger chunks lead to coarser garbage collection. Good or bad depending on use case. /// * Larger chunks lead to less precision in e.g. the time panel. Bad. /// /// Empirical testing shows that the space overhead gains rapidly diminish beyond ~1000 rows, diff --git a/crates/viewer/re_data_ui/Cargo.toml b/crates/viewer/re_data_ui/Cargo.toml index 8b3002d4d0cc..0902356b3d17 100644 --- a/crates/viewer/re_data_ui/Cargo.toml +++ b/crates/viewer/re_data_ui/Cargo.toml @@ -45,3 +45,4 @@ egui.workspace = true image.workspace = true itertools.workspace = true rfd.workspace = true +unindent.workspace = true diff --git a/crates/viewer/re_data_ui/src/entity_db.rs b/crates/viewer/re_data_ui/src/entity_db.rs index acf21d194eef..238d5e096122 100644 --- a/crates/viewer/re_data_ui/src/entity_db.rs +++ b/crates/viewer/re_data_ui/src/entity_db.rs @@ -1,3 +1,4 @@ +use re_chunk_store::ChunkStoreConfig; use re_entity_db::EntityDb; use re_log_types::StoreKind; use re_types::SizeBytes; @@ -101,6 +102,58 @@ impl crate::DataUi for EntityDb { ui.end_row(); } + { + let &ChunkStoreConfig { + enable_changelog: _, + chunk_max_bytes, + chunk_max_rows, + chunk_max_rows_if_unsorted, + } = self.store().config(); + + ui.grid_left_hand_label("Compaction"); + ui.label(format!( + "{} rows ({} if unsorted) or {}", + re_format::format_uint(chunk_max_rows), + re_format::format_uint(chunk_max_rows_if_unsorted), + re_format::format_bytes(chunk_max_bytes as _), + )) + .on_hover_text( + unindent::unindent(&format!("\ + The current compaction configuration for this recording is to merge chunks until they \ + reach either a maximum of {} rows ({} if unsorted) or {}, whichever comes first. + + The viewer compacts chunks together as they come in, in order to find the right \ + balance between space and compute overhead. + This is not to be confused with the SDK's batcher, which does a similar job, with \ + different goals and constraints, on the logging side (SDK). + These two functions (SDK batcher & viewer compactor) complement each other. + + Higher thresholds generally translate to better space overhead, but require more compute \ + for both ingestion and queries. + Lower thresholds generally translate to worse space overhead, but faster ingestion times + and more responsive queries. + This is a broad oversimplification -- use the defaults if unsure, they fit most workfloads well. + + To modify the current configuration, set these environment variables before starting the viewer: + * {} + * {} + * {} + + This compaction process is an ephemeral, in-memory optimization of the Rerun viewer. + It will not modify the recording itself: use the `Save` command if you wish to persist \ + the compacted results, which will make future runs cheaper.\ + ", + re_format::format_uint(chunk_max_rows), + re_format::format_uint(chunk_max_rows_if_unsorted), + re_format::format_bytes(chunk_max_bytes as _), + ChunkStoreConfig::ENV_CHUNK_MAX_ROWS, + ChunkStoreConfig::ENV_CHUNK_MAX_ROWS_IF_UNSORTED, + ChunkStoreConfig::ENV_CHUNK_MAX_BYTES, + )), + ); + ui.end_row(); + } + if let Some(data_source) = &self.data_source { ui.grid_left_hand_label("Data source"); data_source_button_ui(ctx, ui, data_source);