ONLYOFFICE против LibreOffice: тест скорости и памяти

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

В тестах версий LibreOffice 25.8.4.2 и ONLYOFFICE 9 от 31 марта 2026 года преимущество LibreOffice проявилось в ресурсных сценариях. Calc обработал формулу SUMIF по 10 000 строк примерно за 1 секунду против 10 секунд у ONLYOFFICE. При открытии файла LibreOffice использовал около 115 МБ оперативной памяти, тогда как ONLYOFFICE — около 210 МБ. При этом ONLYOFFICE сохраняет сильную сторону в совместимости с форматами Microsoft Office, что делает выбор не однозначным.

Архитектура: нативный C++ против Electron

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

ONLYOFFICE Desktop Editors построен иначе. Его настольная оболочка использует Electron, а вместе с ним — Node.js и компоненты Chromium. Такой подход позволяет унифицировать поведение интерфейса и приблизить настольный продукт к веб-версии. Для разработчика это рациональная модель: часть программной логики можно переиспользовать между платформами, а визуальное представление документов получает более единый механизм.

Цена унификации — дополнительный слой исполнения. Electron запускает не только редактор документа, но и среду, в которой этот редактор работает. В память загружаются процессы оболочки, JavaScript-движок, элементы Chromium и служебные компоненты Node.js. Даже если пользователь еще не открыл текстовый документ или таблицу, базовая инфраструктура уже заняла часть ОЗУ.

Производительность офисного пакета определяется не только вычислительным ядром документа. Существенную роль играет среда, в которой это ядро запущено.

У LibreOffice также есть собственные фоновые компоненты и служебные процессы, поэтому сравнение не сводится к формуле «C++ всегда экономичнее Electron». Однако в рассматриваемых тестах разница проявилась именно на уровне базовой нагрузки и операций, где важны прямой доступ к памяти, диску и файловой системе.

Архитектурный выбор влияет и на характер задержек. В нативном приложении распределение памяти и взаимодействие между модулями контролируются внутренними механизмами самого пакета. В Electron часть операций проходит через универсальную среду, рассчитанную на широкий круг приложений. Для текстового редактора это удобно с точки зрения разработки и совместимости интерфейса, но не всегда оптимально с точки зрения минимального потребления ресурсов.

Потребление оперативной памяти: разница начинается до открытия файла

Вопрос «ONLYOFFICE или LibreOffice: потребление оперативной памяти» имеет два уровня. Первый — сколько памяти занимает приложение сразу после запуска. Второй — как меняется нагрузка после открытия документа, таблицы, макросов и сетевого файла.

В тесте без открытых документов ONLYOFFICE требовал около 327 МБ ОЗУ только для работы Electron-оболочки и Node.js-окружения. Это не объем памяти, который занимает конкретный документ. Это базовая стоимость запуска среды. На компьютере с 8 ГБ оперативной памяти 327 МБ не выглядят критичной цифрой, но офисное приложение редко работает в изоляции.

Параллельно могут быть запущены браузер с десятками вкладок, почтовый клиент, мессенджер, IDE, виртуальная машина или несколько PDF-документов. В такой конфигурации постоянная базовая нагрузка становится частью общего давления на планировщик задач и подсистему виртуальной памяти. Если физическая память заканчивается, операционная система начинает активнее использовать swap или файл подкачки. Это увеличивает задержки даже в тех операциях, которые сами по себе не являются вычислительно тяжелыми.

LibreOffice в сопоставимом сценарии ведет себя экономичнее. При открытии тестового файла он использовал около 115 МБ ОЗУ против примерно 210 МБ у ONLYOFFICE. Разница составляет около 95 МБ на одном документе. Для одного файла это умеренное значение, но при одновременной работе с несколькими документами или несколькими экземплярами редактора оно становится заметнее.

Эти значения нельзя трактовать как универсальный паспорт всех редакций и платформ. Потребление памяти зависит от версии, операционной системы, размера документа, встроенной графики, подключенных словарей и фоновых служб. Но направление различия понятно: ONLYOFFICE предъявляет более высокие требования к свободному объему ОЗУ уже на этапе запуска.

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

Calc против табличного редактора ONLYOFFICE: где проявляется разница в скорости

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

В тесте с функцией SUMIF по 10 000 строк LibreOffice Calc выполнил расчет примерно за 1 секунду. ONLYOFFICE затратил около 10 секунд. Разница десятикратная. Для небольшой таблицы пользователь может не заметить задержку или воспринять ее как единичный сбой. Но при регулярной работе с отчетами, реестрами и выгрузками это уже влияет на производственный цикл.

Функция SUMIF относится к базовым операциям условного суммирования. Она не моделирует весь спектр возможностей электронных таблиц, однако хорошо показывает стоимость пересчета диапазона, когда редактор должен проверить условие в каждой строке и собрать итоговое значение.

Причины разницы могут быть связаны с несколькими уровнями системы:

1. Вычислительное ядро. Табличный редактор должен пройти по диапазону, вычислить условие, обратиться к значениям ячеек и обновить зависимые результаты. Реализация этих операций определяет основную часть времени расчета.

2. Распределение памяти. При обработке формул приложение создает промежуточные структуры данных. Нативный код обычно дает разработчику более прямой контроль над такими объектами, тогда как среда с автоматическим управлением памятью может добавлять накладные расходы.

3. Граф зависимостей. После изменения значения редактор определяет, какие формулы необходимо пересчитать. Чем эффективнее построен этот граф, тем меньше лишних операций выполняется при обновлении таблицы.

4. Обновление интерфейса. После завершения вычислений редактор должен отобразить новые значения. Если пересчет, отрисовка и обработка событий пользователя конкурируют за ресурсы, задержка воспринимается сильнее, чем показывает чистое время вычисления.

Показатель 1 против 10 секунд не означает, что LibreOffice будет в десять раз быстрее в любой таблице. Формулы с другими функциями, сводные таблицы, внешние ссылки, условное форматирование и макросы создают другую структуру нагрузки. На результат также влияют размер файла и аппаратная конфигурация.

Тем не менее это существенный сигнал для пользователей, работающих с большими расчетными книгами. Если таблица содержит десятки тысяч строк и регулярно пересчитывается после импорта данных, разница между пакетами будет выражаться не в абстрактном бенчмарке, а в минутах ожидания на протяжении рабочего дня.

Макросы и запись на диск

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

В тестах скорость записи файлов на диск при выполнении макросов в LibreOffice была примерно в 2,5 раза выше. Преимущество связывается с прямой работой пакета с собственной файловой подсистемой и меньшим числом промежуточных слоев.

Здесь необходимо разделять два показателя. Скорость записи отдельного файла и полное время выполнения макроса — не одно и то же. Макрос может тратить большую часть времени на обработку таблицы, обращение к объектной модели или ожидание внешних ресурсов. Но если автоматизация часто сохраняет документы, создает копии или экспортирует результаты, разница файлового уровня начинает влиять на общий цикл.

Для корпоративных сценариев это особенно заметно в пакетной обработке:

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

При этом нельзя автоматически переносить результат теста макросов на любую автоматизацию в ONLYOFFICE. Разные языки сценариев, объектные модели и способы обращения к документу меняют характер нагрузки. Производительность конкретного макроса следует оценивать на его реальном наборе операций.

Сетевые папки SMB: узкое место находится не в процессоре

Работа с локальным диском и работа с сетевой папкой — разные классы задач. При обращении к SMB редактор зависит от задержки сети, механизма блокировок, количества файловых запросов и того, как приложение обрабатывает метаданные документа. Если пакет выполняет много последовательных обращений, скорость канала сама по себе не гарантирует быструю загрузку.

В средах Linux с рабочими окружениями XFCE и MATE LibreOffice открывал файл через SMB примерно за 3 секунды. ONLYOFFICE требовалось до 25 секунд. До 22 дополнительных секунд ожидания на одном документе могут показаться терпимыми, но при постоянной работе с сетевым архивом они превращаются в систематическую задержку, которая отвлекает от содержательной задачи и расходует рабочее время.

Здесь Electron-архитектура проявляет себя не только через расход памяти. Универсальная оболочка должна корректно связать настольное окно, внутренние компоненты редактора и операционные механизмы доступа к файлам. Для локального SSD это может оставаться незаметным. Сетевой ресурс усиливает цену каждого дополнительного шага.

Сценарий с SMB важен для Linux-рабочих мест, небольших серверных офисов и домашних сетей, где документы хранятся на NAS. Пользователь может открыть файл с локального диска без выраженных проблем, а затем столкнуться с задержкой при работе с тем же документом через сетевой каталог. Поэтому тестировать офисный пакет следует не только на локальной копии, но и в среде, где он будет использоваться ежедневно.

Если документы находятся на SMB-ресурсе, скорость приложения определяется не только производительностью процессора. Количество файловых обращений и поведение оболочки становятся самостоятельным фактором.

Отдельно следует учитывать блокировки и конкурентный доступ. Если несколько пользователей редактируют документы из общей папки, поведение зависит от формата, настроек сервера и механизма временных файлов. Быстрое открытие документа не гарантирует безопасной совместной работы. Но именно в части первичной загрузки файлов LibreOffice показал более короткое время в приведенном Linux-сценарии.

Совместимость форматов меняет итог сравнения

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

Если организация ежедневно получает документы DOCX и XLSX от внешних контрагентов, важна не только скорость пересчета. Значение имеют сохранение разметки, расположение объектов, поведение сложных таблиц, поддержка элементов форматирования и предсказуемость повторного открытия файла в Microsoft Office.

Именно здесь ONLYOFFICE часто выбирают несмотря на повышенное потребление памяти. Совместимость снижает риск ручного исправления документов после обмена. Экономия нескольких сотен мегабайт ОЗУ не компенсирует часы, потраченные на восстановление макета отчета или проверку формул после преобразования.

LibreOffice, в свою очередь, особенно рационален там, где приоритетом являются:

• работа с локальными документами и таблицами;
• обработка больших диапазонов и регулярный пересчет формул;
• запуск на компьютерах с 8 ГБ ОЗУ;
• использование Linux-систем с XFCE или MATE;
• автоматизация через макросы и массовая запись файлов;
• минимальная зависимость от тяжелой настольной оболочки.

ONLYOFFICE логичнее рассматривать в другой конфигурации требований:

• компьютер оснащен 16 ГБ ОЗУ или больше;
• основной обмен идет с пользователями Microsoft Office;
• сохранение исходной структуры DOCX и XLSX важнее минимальной нагрузки;
• документы используются как часть единой экосистемы настольных и веб-редакторов;
• локальная производительность не является ограничивающим фактором.

Это не означает, что совместимость ONLYOFFICE одинакова для каждого документа. Сложные макросы, нестандартные шрифты, встроенные объекты и специфические функции таблиц по-прежнему требуют проверки. Но в общем выборе офисного пакета данный критерий способен перевесить результаты синтетического теста.

Какой офис быстрее: LibreOffice или ONLYOFFICE

Ответ зависит от операции, но по зафиксированным сценариям картина достаточно последовательная.

LibreOffice быстрее и экономичнее в задачах, где нагрузка ложится на вычислительное ядро, файловую подсистему и работу с ограниченным объемом памяти. Это подтверждается расчетом SUMIF на 10 000 строк, записью файлов во время макросов и открытием документа через SMB. Его нативная архитектура дает преимущества там, где важны короткая цепочка исполнения и низкие накладные расходы.

ONLYOFFICE требует больше ресурсов из-за Electron и Node.js. Базовое потребление около 327 МБ при запуске без документов — главный показатель архитектурной цены. На компьютере с 16 ГБ ОЗУ эта нагрузка обычно не становится проблемой. На системе с 8 ГБ она заметнее, особенно при одновременной работе браузера, почтового клиента и нескольких документов.

Таким образом, выбор пакета остается за пользователем, но результаты теста дают понятный ориентир. Если приоритетом является минимальное потребление оперативной памяти, скорость пересчета формул и устойчивость на системах с 8 ГБ ОЗУ, LibreOffice подходит лучше. Если же работа строится вокруг документов Microsoft Office, в инфраструктуре достаточно памяти и важна единая логика между настольной и веб-версией, ONLYOFFICE оправдывает дополнительную нагрузку. Это не вопрос «какой офис объективно быстрее» — это вопрос, какая метрика важнее в конкретном сценарии.