GC improvements 1: fix timeless tables not being RowId-ordered

[teh-cmc]

Fixes a long-standing bug: timeless tables not being sorted by RowId, which means they effectively always return incorrect results for out-of-order data (yes, that is a thing even in a timeless context).

This worsens GC performance for timeless tables, but:

1. The performance of incorrect code hardly matters to begin with, and
2. this is ground work for turning timeless tables in ringbuffers in an upcoming PR, which will massively improve performance.

• Fixes datastore: timeless ordering should be RowId-based #1807

Benchmarks

Hint: it's even worse!

group                                                     gc_improvements_0                       gc_improvements_1
-----                                                     -----------------                       -----------------
.../plotting_dashboard/drop_at_least=0.3/bucketsz=1024    1.00   1084.0±4.47ms 54.1 KElem/sec     1.03   1117.2±9.07ms 52.4 KElem/sec
.../plotting_dashboard/drop_at_least=0.3/bucketsz=2048    1.00       2.1±0.02s 27.6 KElem/sec     1.01       2.1±0.01s 27.3 KElem/sec
.../plotting_dashboard/drop_at_least=0.3/bucketsz=256     1.00    465.8±2.50ms 125.8 KElem/sec    1.01    471.5±4.76ms 124.3 KElem/sec
.../plotting_dashboard/drop_at_least=0.3/bucketsz=512     1.00    655.3±2.61ms 89.4 KElem/sec     1.02    666.7±6.64ms 87.9 KElem/sec
.../plotting_dashboard/drop_at_least=0.3/default          1.00    652.8±4.12ms 89.8 KElem/sec     1.02    665.6±4.67ms 88.0 KElem/sec
.../timeless_logs/drop_at_least=0.3/bucketsz=1024         1.00       2.4±0.05s 24.2 KElem/sec     3.35       8.1±0.10s  7.2 KElem/sec
.../timeless_logs/drop_at_least=0.3/bucketsz=2048         1.00       2.4±0.03s 24.1 KElem/sec     3.30       8.0±0.09s  7.3 KElem/sec
.../timeless_logs/drop_at_least=0.3/bucketsz=256          1.00       2.5±0.08s 23.5 KElem/sec     3.23       8.1±0.11s  7.3 KElem/sec
.../timeless_logs/drop_at_least=0.3/bucketsz=512          1.00       2.4±0.02s 24.5 KElem/sec     3.38       8.1±0.11s  7.3 KElem/sec
.../timeless_logs/drop_at_least=0.3/default               1.00       2.4±0.03s 24.4 KElem/sec     3.35       8.1±0.07s  7.3 KElem/sec

---

Part of the GC improvements series:

• GC improvements 0: use-case driven benchmarks #4394
• GC improvements 1: fix timeless tables not being RowId-ordered #4395
• GC improvements 2: VecDeque extensions & benchmarks #4396
• GC improvements 3: turn datastore columns into ring-buffers #4397
• GC improvements 4: index EntityPathHashes in metadata registry #4398
• GC improvements 5: Store{Diff,Event} optimizations #4399
• GC improvements 6: introduce batched GC #4400
• GC improvements 7: introduce time_budget GC setting #4401

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested app.rerun.io (if applicable)
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[Wumpf]

looking great!

[Wumpf]

overviews like that a very appreciated :)

[Wumpf]

offtopic, but this way of counting the size of a struct (and what it points to) isn't all that accurate since padding between fields can play a big role :/. Not that it matters all that much in the big picture here

[teh-cmc]

Yep, the stats are not meant to be perfectly accurate, they just need to be "good enough" and more importantly consistent: since the GC works with percentages rather than raw numbers, as long as things are consistent it works out okay.

By far our biggest problem at the moment is the size of serialized arrow data, which is both wrong and inconsistent in many ways lol.

Quoting the docs:

/// The size of both the control & component data stored in this bucket, heap and stack
/// included, in bytes.
///
/// This is a best-effort approximation, adequate for most purposes (stats,
/// triggering GCs, …).