Предыдущие посты серии:
1. Документация по промптам.
2. Выбор нейронок.
3. Подготовка к разработке.
4. Оптимизация кода.
5. Если код не "летает".
✅ При неоднократном обращении к таблицам и спискам:
⚫️ Буферизуем их (кешируем) в начале запроса.
⚫️ Используем при фильтрации буферизованные списки и таблицы, но с таблицами нужно быть очень аккуратными, об этом — ниже.
————
✅ Буферизуем в Power Query:
⚫️ Списки для фильтрации и проверки наличия.
Если список используется многократно в
List.Select, List.Contains или для создания HashSet — оборачиваем в List.Buffer. Это гарантирует, что список будет вычислен один раз и сохранён в памяти.⚫️ Списки перед созданием
Record (HashMap).Перед вызовом
Record.FromList буферизуем исходный список ключей. Сам Record после создания буферизовать не нужно — он уже в памяти.⚫️ Таблицы-справочники.
Небольшие таблицы, которые используются для поиска значений (
lookup), лемматизации, замен и подобных операций. Буферизуем через Table.Buffer перед созданием из них Record-словаря.⚫️ Объединение таблиц.
При
Table.NestedJoin или Table.Join таблицы читаются многократно. Буферизация предотвращает повторное вычисление. Но первую таблицу буферизовать опасно, если она большая.Table.Join гораздо быстрее, чем Table.NestedJoin⚫️ Небольшие внешние источники данных.
Таблицы из Excel-файлов, CSV, API и других внешних источников буферизуем для исключения повторного их чтения ТОЛЬКО ЕСЛИ:
а) они небольшие.
б) вы обращаетесь к ним более одного раза.
————
✖ Не буферизуем в Power Query:
⚫️ Большие таблицы (например, выгрузка статистики рекламного кабинета).
Таблицы свыше 100–200 тысяч строк буферизовать опасно — это может привести к ошибке Out of Memory или сильному замедлению. Для больших данных используем потоковую обработку.
⚫️ Широкие таблицы.
Даже если строк немного, таблица с 20+ столбцами занимает много памяти. Перед буферизацией лучше оставить только нужные столбцы через
Table.SelectColumns.⚫️ Промежуточные шаги в цепочке преобразований.
Power Query использует ленивые вычисления — данные обрабатываются потоково, без материализации промежуточных результатов. Буферизация каждого шага убивает это преимущество.
⚫️ Результат
Table.Group.Группировка уже материализует результат. Дополнительная буферизация не даёт выигрыша.
⚫️
Record (HashMap).После создания через
Record.FromList словарь уже находится в памяти. Буферизовать его не нужно и невозможно — функции List.Buffer и Table.Buffer к нему не применимы.————
✅ Ориентиры по размерам, буферизовать ли данные:
— Списки до 100 тысяч строк — буферизовать безопасно.
— Таблицы до 50 тысяч строк и шириной до 10 столбцов — буферизовать безопасно.
— Таблицы от 50 до 200 тысяч строк — буферизуем только если это действительно необходимо и есть запас оперативной памяти.
— Таблицы свыше 200 тысяч строк не буферизуем, а используем потоковую обработку с фильтрацией до объединения.
Точные пороги необходимости буферизации зависят от:
а) Доступной оперативной памяти на ПК.
б) Высоты и ширины исходных таблиц.
в) Будет ли этот датасет со временем пополняться, т.е. масштабируемый ли это будет код или он вернет ошибку нехватки памяти при первой же обработке массива побольше тестового.
————
✅ Если не понимаете, почему фильтрация или сортировка выполняются долго, скажите нейронке:
1. Проанализируй код на предмет сложности вычислений из «Big O» нотации:
От самых быстрых:
— O(1) — константное время.
— O(log n) — логарифмическое.
— O(n) — линейное.
— O(n + m) — линейное время от двух входов.
К самым медленным:
— O(n log n) — линейно-логарифмическое время.
— O(n × m) — бинейное.
— O(n²) — квадратичное.
— O(nᵏ) — степенное.
— O(2ⁿ) — экспоненциальное.
— O(n!) — факториальное.
2. Перепиши код с использованием самых быстрых из возможных вычислений: O(1), O(log n), O(n), O(n + m).
3. Не используй функции с медленными вычислениями: O(n log n), O(n × m), O(n²), O(nᵏ), O(2ⁿ), O(n!).
В следующем посте — пример, не понимая матчасть которого, ждать обработку придется вечность.
via @ppc_bigbrain