Производительность и память

Первый инструмент — бенчмарк testing.B: тело с приёмом b повторяется фреймворком b.N раз, и Go печатает среднее время на операцию вместе с аллокациями. Бенчмарк отвечает на вопрос «сколько», но не на вопрос «где»: для второго существует pprof — профиль процессора и памяти, который показывает функции-рекордсмены. Грубая прикидка в один глаз — time.Now и time.Since вокруг подозрительного участка, а для памяти — runtime.ReadMemStats с полем HeapAlloc до и после генерации. Два правила замера экономят дни. Первое: мерить на данных, по форме похожих на боевые, — цифры, снятые на сотне строк, ничего не говорят о миллионе. Второе: мерить на одной и той же машине без параллельной нагрузки — числа, снятые рядом с пересборкой проекта, не сравниваются между собой. Excelize производительность — это не одна цифра, а соотношение работы библиотеки, вашего кода и окружения, и разницу замечают только при равных условиях.

Первый расход — GetRows и его родственники: вызов собирает весь лист в срез срезов строк, и на листе в миллион строк такой срез занимает гигабайт плюс накладные расходы на каждую строку. Второй — стили: каждый вызов NewStyle добавляет запись в таблицу стилей книги, и вызов в цикле по ячейкам раздувает память при сборке, сам файл и время его открытия в Excel. Третий — итоговый документ в буфере: WriteToBuffer собирает файл целиком в памяти, и на сотнях мегабайт данных это удваивает расход, поэтому для больших выгрузок StreamWriter из урока про потоковую запись — рабочий инструмент, а не украшение. Четвёртый расход тише: строковый мусор — координаты ячеек, промежуточные срезы, копии значений; по отдельности мелочь, на миллионе строк — заметная доля, которую видно по аллокациям бенчмарка. Последний пункт простой: не держите открытыми десятки книг одновременно — каждая живёт со своими XML-частями до Close, и память excelize складывается по всем книгам, а не только по самым тяжёлым.

У формата xlsx лимит листа — 1 048 576 строк и 16 384 колонки, и excelize вернёт ошибку, когда запись уйдёт за границу. Реальный потолок наступает раньше: память окружения — контейнер с двумя гигабайтами не соберёт отчёт, на который при сборке уходит четыре, а механизм изоляции убьёт процесс тихо, без стектрейса в логе. После сборки свой лимит наступает у читателя: файл на сотни мегабайт открывается в Excel ощутимо дольше, и человек с машиной попроще получает фактически недоступный отчёт. Практический вывод: узнайте лимиты своего окружения до релиза — память пода, ограничения на размер файла в интерфейсе, договорённость с заказчиком о том, что он вообще открывает. Разбивка на части, выгрузка частями по месяцам или архив с несколькими книгами — эти решения дешевле принять на этапе дизайна, чем на этапе инцидента ночью.

Оптимизация без замера — лотерея, поэтому план короткий и дисциплинированный. Сначала базовый замер: бенчмарк на правдоподобных данных, время и память зафиксированы в заметке или в CI. Затем профиль: pprof покажет, куда уходит время, — иногда это не excelize, а запрос к базе, сериализация или ваш код преобразования значений, и тогда править нужно не библиотеку. Дальше одно изменение за раз: кэш стилей, итератор вместо GetRows, StreamWriter вместо обычной записи, CoordinatesToCellName вместо Sprintf — и сразу повторный замер по той же методике. Если цифры не сдвинулись, изменение откатывается или остаётся по другим соображениям, например по читаемости. В конце — тесты содержимого: оптимизация, которая сломала файл, не считается оптимизацией, и здесь пригодится урок про тесты генерации, где результат проверяется чтением обратно и golden-снимками. Так excelize производительность улучшается шагами, каждый из которых объясняется цифрой коллегам и вам самим через месяц.