LibreOffice и ONLYOFFICE: тест скорости и потребления памяти

Выбор между LibreOffice и ONLYOFFICE давно перестал быть дискуссией о лицензировании и открытом коде. В 2026 году под вопросом оказывается архитектурный фундамент обоих пакетов: классическая нативная сборка против обёртки на базе Electron и Node.js. Это различие определяет нагрузку на подсистему памяти, скорость пересчёта формул и распределение процессорного времени между фоновыми задачами. Пользователь, привыкший работать с одним инструментом, переносит на новый пакет не только навыки, но и ожидания по отзывчивости интерфейса.

Замеры на идентичных сценариях дают неоднозначный результат. У каждого пакета свои сильные стороны: LibreOffice эффективнее расходует память в условиях многозадачности и быстрее обрабатывает табличные формулы, тогда как ONLYOFFICE выигрывает в скорости запуска на macOS и обеспечивает более плотную совместимость с форматами Microsoft Office. Универсального победителя нет, есть карта компромиссов, которую необходимо читать под собственные задачи.

Архитектурная пропасть: нативная сборка против Electron-оболочки

LibreOffice построен на нативной кодовой базе C++ с использованием графического тулкита GTK или Qt в зависимости от дистрибутива и операционной системы. Ядро пакета не зависит от стороннего JavaScript-движка. Механизм рендеринга и слой интерфейса связаны через проверенные временем C-API, что минимизирует накладные расходы при инициализации процесса. Это фундаментальное свойство: каждый модуль работает в едином адресном пространстве без сериализации через IPC.

ONLYOFFICE использует иной подход. Интерфейсная часть реализована на базе фреймворка Electron, который сам по себе является оболочкой над проектом Chromium. К ней добавляется фоновый процесс Node.js, обеспечивающий взаимодействие с движком документов на C++. При запуске приложения система порождает минимум три процесса с собственным адресным пространством: основной процесс рендеринга, GPU-процесс и backend-процесс Node.js. Каждый из них поддерживает собственный heap, JIT-компилятор и очереди событий.

Только лишь фреймворк Electron в составе ONLYOFFICE при старте занимает около 327 МБ оперативной памяти, это базовый налог, который пользователь платит вне зависимости от характера работы с документами.

Это различие объясняет многие расхождения в замерах, которые фиксируются ниже. Архитектура — не косметический признак, а структурный фактор производительности, который невозможно компенсировать оптимизацией на уровне отдельных модулей.

Потребление оперативной памяти: базовый расход и работа с тяжёлыми файлами

Замеры на идентичной конфигурации под управлением Linux при открытии крупной электронной таблицы показывают: LibreOffice Calc удерживает в оперативной памяти около 701 254 КиБ, тогда как ONLYOFFICE ограничивается 618 188 КиБ. По этому параметру ONLYOFFICE выглядит экономнее. Разница кажется убедительной: около 12% в пользу ONLYOFFICE на конкретной операции.

Картина меняется при учёте базовой нагрузки до открытия документа. Процесс ONLYOFFICE при запуске без единого открытого файла уже требует около 327 МБ ОЗУ под собственный движок рендеринга и Node.js-окружение. У LibreOffice этот показатель существенно ниже за счёт нативного исполнения: пакет не нуждается во внешнем браузерном движке для отрисовки интерфейса и использует системные библиотеки графического стека напрямую.

В условиях реальной многозадачности это означает, что на машинах с 8 ГБ ОЗУ и активным браузером LibreOffice оставляет больше свободного адресного пространства для прикладных задач. ONLYOFFICE при параллельной работе с несколькими ресурсоёмкими приложениями быстрее выходит на порог подкачки.

Для текстовых документов сопоставимые замеры потребления памяти в идентичном кроссплатформенном тесте пока недоступны — это ограничение существующих моделей бенчмаркинга, а не свойств самих пакетов. Модули Writer и Document Editor требуют отдельного исследования с привлечением идентичной аппаратной конфигурации.

Скорость вычислений и обработки данных в табличных процессорах

Расхождения между пакетами проявляются наиболее ярко в табличных процессорах. В тесте на 10 000 строк с функцией SUMIF на процессоре Intel i3-8100 LibreOffice Calc справился за 1 секунду. ONLYOFFICE на той же задаче затратил порядка 10 секунд. Разница в десять раз объяснима не только архитектурой, но и реализацией вычислительного ядра.

LibreOffice использует собственный механизм пересчёта зависимостей на C++, оптимизированный за десятилетия развития проекта. Граф зависимостей между ячейками хранится в памяти в компактной форме, и пересчёт охватывает только изменённые диапазоны. Это свойство давно выделяет пакет в академической и инженерной среде, где табличные книги достигают десятков тысяч формул.

ONLYOFFICE наследует модель расчётов из исходного кода, исторически ориентированного на совместимость с Microsoft Excel, но не на максимальную скорость обработки крупных формульных массивов. Дополнительный слой абстракции между скриптовым ядром и движком документа удлиняет путь каждого вызова функции.

Десятикратное расхождение между пакетами при одинаковой формуле — это не оптимизация и не частный случай, а следствие различных вычислительных архитектур.

При копировании и вставке диапазонов с формулами в файлах объёмом 1,3–1,8 МБ пользователи фиксируют задержки 3–6 секунд в ONLYOFFICE. Конкретные значения задержек в LibreOffice для этого же сценария зависят от конфигурации и версии пакета, и в открытых бенчмарках эта разница не зафиксирована как стабильный результат. Для пользователей, работающих с таблицами как основным инструментом анализа, относительное преимущество LibreOffice в вычислительных задачах сохраняется, но его проявление в операциях копирования определяется характером данных и нагрузкой на конкретную сессию.

Отзывчивость интерфейса: запуск приложений и работа с текстом

Время запуска пакетов различается по платформам. На macOS LibreOffice загружается 5–7 секунд, тогда как ONLYOFFICE отображает основное окно заметно быстрее благодаря кэшированию Electron-окружения между сессиями. Это объясняется тем, что Chromium-движок при повторном запуске использует прогретый кэш шрифтов и библиотек в системной памяти.

Под Windows относительное преимущество меняется в зависимости от конфигурации. Нативная сборка LibreOffice обходится без инициализации Chromium-движка и не требует JIT-компиляции JavaScript-окружения, что на части конфигураций сокращает холодный старт. ONLYOFFICE компенсирует это кэшированием при повторных запусках в течение одной сессии. Итоговый баланс зависит от оборудования, версии операционной системы и накопленного кэша, поэтому фиксированного преимущества одного пакета в этой ситуации нет: на одних машинах разница заметна, на других сглаживается.

Для работы с текстовыми документами малого и среднего объёма разница в отзывчивости интерфейса минимальна. Оба пакета обеспечивают приемлемый отклик при наборе и форматировании. В сценариях с длинными документами расхождение становится ощутимым, но его конкретный характер зависит от конфигурации. Архитектурно LibreOffice рендерит содержимое через нативный графический стек, что структурно снижает вероятность микроподвисаний при быстрой прокрутке. ONLYOFFICE обрабатывает те же сценарии через виртуализированный рендеринг Chromium, где путь от модели документа до отрисовки проходит через дополнительные слои. На практике итог зависит от плотности страницы, объёма графики, версии движка и состояния кэша, поэтому однозначного вывода о стабильности частоты кадров в обоих пакетах сделать нельзя.

Влияние разных версий Java на скорость работы LibreOffice в современных дистрибутивах Linux остаётся недоисследованным в открытых бенчмарках. Это параметр, способный сдвинуть показатели как в одну, так и в другую сторону в зависимости от конфигурации среды исполнения и наличия специфических расширений пакета.

Фоновые задачи, проверка орфографии и производительность макросов

Проверка орфографии представляет характерный пример расхождения в эффективности фоновых процессов. Замеры показывают, что ONLYOFFICE потребляет примерно в 2,9 раза больше процессорного времени при проверке орфографии по сравнению с нативной интеграцией Hunspell в LibreOffice. Причина структурная: путь от документа к словарю через Electron и Node.js добавляет лишние IPC-переходы и сериализации. На каждый вызов проверки слова тратится больше процессорных циклов, чем при прямом обращении к словарной базе через C-API.

Макросы попадают в зону архитектурных различий, но сравнение здесь не однозначно. LibreOffice использует StarBasic (диалект Basic) с интеграцией в ядро через C-API, что даёт прямой доступ к объектной модели документа. ONLYOFFICE предлагает JavaScript API, исполняемый через движок, встроенный в Node.js-окружение. Это удобно для веб-разработчиков, но вносит дополнительный слой абстракции между скриптом и структурой документа.

В тестах на запись и чтение сетки 1000×1000 ячеек LibreOffice Calc показал скорость выполнения на порядок ниже, чем VBA-среда Microsoft Excel. Скорость записи файлов на диск у LibreOffice оказалась в 2,5 раза выше, чем у VBA. Это объясняется прямой работой с собственной файловой подсистемой пакета в обход трансляции через прослойку совместимости.

Здесь важен нюанс: скорость выполнения макросов нельзя свести к одному пакету как безусловному победителю. Итоговый результат зависит от типа операции, объёма обрабатываемого диапазона и используемого языка скрипта. На операциях чтения и записи выигрывает LibreOffice, на операциях с интенсивной работой строковых функций разница сокращается.

В сценариях с несколькими одновременно открытыми документами нагрузка на систему растёт у обоих пакетов, но конкретный профиль потребления зависит от конфигурации и набора активных функций. Архитектурно LibreOffice обходится меньшим числом фоновых процессов, тогда как ONLYOFFICE добавляет к каждому окну собственный набор Chromium-процессов. Реальное распределение ресурсов между процессором и памятью при параллельной работе с несколькими файлами зависит от объёма каждого документа, состояния автопроверки орфографии, активности фонового сохранения и конкретной версии пакетов, поэтому однозначный вывод о преимуществе здесь делать рискованно: на одной конфигурации разница выражена, на другой нивелируется.

Позиция по выбору

LibreOffice в этой паре выигрывает по совокупности технических параметров: меньшая базовая нагрузка на память, более высокая скорость расчёта формул, лучшая интеграция словарной проверки, меньшие накладные расходы на IPC-переходы между модулями. На машинных конфигурациях с 8 ГБ ОЗУ и без дискретного ускорителя нативная сборка пакета оставляет больше ресурсов для параллельной работы с браузером и коммуникационными приложениями.

ONLYOFFICE оправдан в сценариях, где критична максимальная совместимость с форматами Microsoft Office и приоритет отдаётся единству интерфейса между десктопной и облачной версиями пакета. На устройствах с 16 ГБ ОЗУ и более мощной начинкой базовая нагрузка Electron-оболочки растворяется в общем бюджете системы. Здесь архитектурный штраф становится приемлемой ценой за плотную совместимость форматов и знакомый интерфейс для пользователей, мигрирующих с Microsoft Office.

При выборе альтернативы Microsoft Office пользователь платит за лицензию экономию ресурсов системы. Этот обмен не всегда линеен, переход на свободный офисный пакет требует не только отказа от подписки, но и пересмотра сценариев работы с документами. Для машин с ограниченной оперативной памятью и приоритетом на работу с таблицами LibreOffice остаётся более рациональным выбором. Для команд с устоявшимися сценариями совместного редактирования в облаке ONLYOFFICE сохраняет функциональное преимущество, если его накладные расходы на производительность укладываются в бюджет оборудования.