Кратко и по существу — сравнение трёх парадигм для реализации отслеживания зависимостей в таблицах, с точки зрения производительности, удобства разработки и отладки, затем пример архитектуры для реактивного подхода.

1) Императивное программирование

Идея: явное состояние (ячейки, значения, граф зависимостей) и явные изменения (изменить значение → обновить граф → рекомпьют).Плюсы по производительности:
Часто самая быстрая реализация в простых случаях: можно делать ин‑place обновления, минимизировать аллокации.Легко оптимизировать обход (например, топологическая сортировка и последовательный update), полная рекомпутация за (O(n+e)) при пересчёте всех узлов ((n) — число ячеек, (e) — число зависимостей).Минусы по производительности:
Вручную сложнее корректно минимизировать повторные пересчёты при параллельных/асинхронных изменениях.Риск гонок и неконсистентных промежуточных состояний при многопоточности.Удобство разработки:
Простая модель для небольших реализаций; код понятен, контролируем.С ростом функциональности (транзакции, отмена, история) код быстро усложняется.Удобство отладки:
Легко поставить точки останова на мутациях состояния.Трудности при расследовании сложных последовательностей обновлений (промежуточные несогласованные состояния).

2) Функциональное программирование

Идея: неизменяемые структуры, чистые функции для вычисления значений ячеек, зависимости представлены как выражения; изменения создают новые верcии состояния.Плюсы по производительности:
Возможность безопасной параллельной оценки; агрессивные оптимизации (мемоизация, ленивость).С помощью структур данных с постоянством (persistent data structures) можно делать частичные копии эффективно (амортизированно).Инкрементальные подходы (формулы как чистые функции) позволяют легко кешировать результаты.Минусы по производительности:
Без специализированных структур возможны дополнительные аллокации и копирование, что даёт накладные расходы.Требуется грамотная стратегия кеширования/инвалидации, иначе полная рекомпутация дорого обходится.Удобство разработки:
Легче обосновать корректность и писать тесты (чистые функции, отсутствие побочных эффектов).Undo/redo, time travel и историчность естественны (версионность состояния).Удобство отладки:
Проще локализовать ошибку в чистой функции; однако отладка распределённых/ленивых вычислений может быть нетривиальна.Trace-логи вычислений и сравнением версий — сильный инструмент.

3) Реактивное программирование

Идея: модель «значение как поток» (observables/streams). Ячейки — реактивные источники; зависимости реализованы как подписки/комбинации потоков; изменения автоматически протекают через сеть сигналов.Плюсы по производительности:
Эффективная инкрементальная рекомпутация: обновляются только зависящие узлы; сложность пропагации пропорциональна затронутой подграфу, примерно (O(k+m)) при затронутых (k) узлах и (m) ребрах.Легко батчировать и дебаунсить события, коалесцировать множественные правки.Поддержка асинхронных источников (сеть, таймеры) «из коробки».Минусы по производительности:
Накладные расходы на управление подписками и диспетчеризацию (особенно при очень большом количестве мелких подписок).Возможны утечки памяти при невыполненном отписывании.Удобство разработки:
Высокоуровневая модель выражения зависимостей (compose, map, combineLatest) делает логику прозрачной и декларативной.При большом количестве побочных эффектов/состояния может потребоваться дополнительный слой управления транзакциями.Удобство отладки:
Отладка временной последовательности событий и причинно‑следственных цепочек бывает сложной (где именно произошёл запуск, какими были предыдущие значения).Зато легко логировать потоки; хорошо работают визуализации потоков и инструментов трассировки.Циклы зависимостей требуют явной обработки (разрыв циклов, фиксация итераций или использование алгоритмов фиксации).

Практические замечания (общие)

Полная рекомпутация: (O(n+e)).Инкрементальная пропагация: (O(k+m)), где (k) — число реально изменённых узлов, (m) — число затронутых ребер.Для всех подходов полезны: топологическая сортировка DAG, маркер «dirty», batching транзакций, версионирование для избежания повторных рекомпутаций.

Пример архитектуры для реактивного подхода (высокоуровнево)
Компоненты:

Ячейка (Cell):
Представлена как реактивный источник/observable с текущим значением и списком подписчиков.Хранит выражение (формулу) или константу.Имеет поле версии (v) и флаг dirty.Декларация зависимостей:
При парсинге формулы для ячейки строится список входных ссылок на другие ячейки (ребра графа).Движок обновлений (Change Propagator / Scheduler):
При редактировании ячейки ставит её в очередь изменений и инкрементирует глобальный счётчик версии (V \leftarrow V+1).Собирает транзакцию: все правки в одном интерактивном событии обрабатываются вместе (batch).Выполняет пропагацию в топологическом порядке (push model) или запрашивает значения лениво (pull model).Коалесцирует несколько быстрых правок в одну рекомпутацию.Evaluator:
Вычисляет выражение ячейки, подписывается на входные observables через механизмы комбинирования (например, combineLatest).Использует кеширование значений и версии для пропуска лишних вычислений: если входные версии не изменились относительно локальной сохранённой версии, пересчёт не нужен.GC подписок:
Удаляет подписки для ячеек, которые больше не используются (weak refs или явный отписчик).UI слой:
Подписан на cell.value; обновляется при изменении.Может отображать индикаторы «пересчитывается», «ошибка», «циклическая зависимость».
Поток данных при редактировании:
Пользователь меняет значение ячейки A.A.emit(newValue); Scheduler помечает A.dirty и помещает в очередь транзакции.Scheduler вычисляет затронутую подгруппу зависимостей (B, C…).В топологическом порядке Evaluator вызывает пересчёт B, C…; при каждом пересчёте проверяется версия входов.После вычислений UI автоматически получает обновлённые значения от подписок и рендерит их.
Механизмы повышения надёжности:Транзакции и батчи: агрегировать изменения за интервал (t) или до конца события UI.Versioning: для каждой ячейки хранить (v_{\text{local}}) и глобальный (V); пересчёт только если входные (v) изменились.Детекция циклов: при построении зависимостей проверять на цикл; либо отвергать формулу, либо применять итерационный метод с контрольной итерацией (i_{\max}).Отладка: логирование событий с timestamp и версией; визуализация DAG и последовательности пропагаций.
Небольшой псевдокод идеи (реактивный push):onEdit(cell, newVal):
cell.value := newVal; cell.version := ++V; enqueue(cell)while queue не пуста:u := dequeue()for each dependent w of u:
if any входы w имеют version > w.version:w.version := ++Vw.value := evaluate(w.expr)enqueue(w)
Заключение (рекомендация)Для простого, быстрого и контроля — императивный подход.Для корректности, тестируемости и удобства параллелизма — функциональный/чистые функции с persistent structures.Для динамической, инкрементальной и асинхронной системы отслеживания зависимостей оптимален реактивный подход с батчингом, версионированием и явной управляющей шиной (Scheduler).