Display compaction information in the recording UI (#6859)

Cargo.lock

@@ -4445,6 +4445,7 @@ dependencies = [
  "re_ui",
  "re_viewer_context",
  "rfd",
+ "unindent",
 ]
 
 [[package]]

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,

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

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);