2f7fdd407be5873dabe2c0c68dc1acaee4030d9b
Change 3 of issue 0133 — rewire compute_visible_rows, filter eval, and sort comparators to read from the SnapshotCache when available. Hot paths rewired: - compute_visible_rows (overload with snap): filter eval uses compare_snap (fast i64/f64 numeric compare for Int/Float cols; id-compare for low-cardinality string Eq/Neq; raw cells fallback for Contains/StartsWith/EndsWith). - Sort comparators: direct i64/f64 array compare for Int/Float cols (goto sort_done skips string fallback); string sort uses uint32_t id compare with pool lookup only on mismatch. - Stage>0 filter/sort: same snapshot overload. Materialization paths (build_so, s0_backing, mat_backing, config popup) kept on raw cells — they copy into std::string anyway, no benefit from snapshot and snprintf-per-cell was 2M extra calls per frame. Bug fixes (required for correctness): 1. StringPool::intern() realloc safety: force reserve before emplace_back so string_view keys in the map never go dangling. 2. SnapshotCache::pool_size_built sentinel: detects when a new State is created with an empty pool but same cells pointer (begin_scenario pattern). Prevents str_ids from indexing into an empty pool (SIGSEGV). 3. Cardinality cap (2048 uniques / 25% sample): high-cardinality string cols (timestamps-as-strings, UUIDs, names) skip interning — str_ids stays empty and compare_snap falls back to raw cells. Prevents 30MB+ pool bloat that hurt cache for filter/sort on other cols. Bench delta vs baseline (100k rows, LIBGL_ALWAYS_SOFTWARE=1): linear_scroll: 16.0 -> 15.5 fps p50 (-3%, baseline already FAIL) filter_like: 59.7 -> 56.0 fps p50 (-6%, still PASS at 56fps) sort_numeric: 3.9 -> 9.0 fps p50 (+131%, snapshot i64 sort) color_rule: 15.2 -> 14.8 fps p50 (-3%, baseline already FAIL) Build: green for all 10 available Linux consumers (text_editor_smoke linker failure is preexisting, not caused by this change). API public intact. TableEvent.row indexing TableInput preserved. Pointer-identity invalidation preserved. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
fn-registry — Schema de documentación
Registry personal de código con búsqueda FTS. Diseñado para composición funcional y agentes.
Archivos
functions.md— Schema de la tabla functions (incluye pipelines y componentes React)types.md— Schema de la tabla typesintegrity.md— Reglas de integridad y referencias cruzadasarchitecture.md— Visión general del sistemasync_setup.md— Vincular una PC al serverregistry.organic-machine.com(env vars,fn sync, troubleshooting)
Tablas
| Tabla | Descripción |
|---|---|
functions |
Funciones atómicas, pipelines y componentes React |
types |
Tipos algebraicos (product / sum) |
kind: valores posibles
| Valor | Descripción |
|---|---|
function |
Función atómica pura o impura |
pipeline |
Composición de funciones, siempre impura |
component |
Componente React, extiende el schema base |
fn-registry schema v1.0
Description
Languages
Go
27.5%
C++
25.5%
Python
24.1%
Shell
11.6%
C
5.8%
Other
5.3%