Текстовые процессоры и их быстродействие: конец ещё одной легенды?

Алексей Федорчук
26 августа 2008 г

С давних пор среди линуксоидов бытует легенда, что OpenOffcie.org вообще и его текстовый процессор OOWriter отличаются от всех прочих программ своей особой медлительностью.

Была прекрасна и чиста
Надежда сноба,
Блондинок линуксом пытал,
Шатал основы
Алиса Деева

Легенда эта восходит ещё к тем временам, когда предтеча OpenOffcie.org назывался StarOffice, разрабатывался фирмой StarDivision и предназначался в основном для OS/2, а его порты на Linux и Windows выпускались так, для мебели. И имела она тогда все основания — с учётом тогдашних машин и объемов памяти.

Существовала и другая легенда тех былинных времён — что на свете есть множество текстовых процессоров, очень лёгких и быстрых, функционально способных заменить не только StarWriter, но и сам MS Word, Великий и Ужасный, да ещё и совместимых с последним. Правда, когда требовалось назвать имена этих легендарных текстовых процессоров, список сводился к Ted’у — действительно легкому объемом и еще более лёгкому функционально (и при этом вполне задумчивому), мифическому Pathetic Writer из пакета Siag, о котором мало кто знал что-то достоверное, кроме того, что он не поддерживает кириллицу, и, возможно LyX’у — программе несколько иного назначения. Что же до совместимости — она реализовывалась на уровне plain text, в лучшем случае — RTF.

Так было до появления на исходе минувшего тысячелетия текстового процессора Abiword. С первых дней его жизни и по сей день немало копий было сломано по поводу его функциональности, устойчивости и совместимости с MS Word. Но пальму первенства по легкости и быстродействию он удерживал прочно — в сравнении не только со StarWriter’ом и с получившим «вольную» OOWriter’ом, но и с вклинившимся в их ряды KWord’ом из пакета KOffice.

Давеча, участвуя в описании пакета Abiword, я снова наткнулся на определения этого текстового процессора как легкого и быстрого. Против первого эпитета никаких возражений не возникало — особенно в сравнении с OpenOffice.org и KOffice, вытащить из которых один текстовый процессор несколько проблематично. А вот второй эпитет, после некоторого периода практической работы с Abiword’ом, рождал в голове смутные сомнения, хотя визуально он по-прежнему казался чрезвычайно быстрым. Что я и решил проверить достаточно простым способом.

Вообще-то, само понятие быстродействия текстового процессора — штука более чем неопределённая, и имеет две стороны — субъективную и «объективную» (почему в кавычках — станет ясно в следующем же абзаце). Субъективно, как я уже сказал, самым быстрым казался Abiword, самым медленным — OOWriter, а KWord занимал промежуточное положение, по визуальному быстродействию тяготея скорее к первому из участников соревнования.

Что же до «объективных» показателей — то они более чем условны. Ведь с какой бы фантастической скоростью ни грузился текстовый процессор, и как бы быстро он ни открывал существующие файлы, пальцы пользователя, набирающего текст, работать быстрее не будут. А если пользователь ещё и задумывается над тем, что он набирает — приходит на память выражение, приписываемое одному из наших покойных Генсеков: «Скорость стука равна скорости звука», но никак не выше.

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

Роль большого файла исполнял документ MS Word (версии 97/2000/XP) объемом 3,8 Мбайт, маленького — также doc-файл объемом 132 Кбайт. Как это выглядит в «бумажном» исполнении, могут представить себе те, кто видел мою книгу «Доступный Unix»: это она вся целиком и введение к ней в электронном виде, по завершении редподготовки. Оба файла были конвертированы в формат ODT посредством OOWriter’а, после чего их объем составил 759 и 38 Кбайт соответственно. На всякий случай они были преобразованы и в родной формат Abiword’а — *abw, в результате чего большой файл увеличился аж до 5,2 Мбайт, а маленький — чуть «усох» до 127 Кбайт (табл. 1).

Табл. 1. Размеры и форматы использованных файлов

Файл/Формат DOC ODT ABW
unix_all 3,8 Мбайт 759 Кбайт 5,2 Мбайт
unix_intro 132 Кбайт 38 Кбайт 127 Кбайт

Первые две пары файлов были отданы на растерзание последовательно OOWriter’у версии 2.4.1, KWord’у версии 1.6.3 и Aboword’у версии 2.6.4 (все три — в штатной сборке дистрибутива Zenwalk). Делалось это на машине с процессором Intel Core 2 Duo/3 Ггц с 4 Гбайт оперативной памяти (конфигурация была подробно описана ранее), в «голой» среде Xfce с единственным открытым окном терминала, в котором последовательно запускались команды вида

$ /usr/bin/oowriter intro.doc

и так далее, для каждого текстового процессора и каждого файла. По причинам, о которым я скажу чуть ниже, считывание одного и того же файла OOWriter’ом производилось как в том же сеансе работы, так и с полной перезагрузкой машины. Время исполнения каждой команды замерялось секундомером — от нажатия клавиши Enter до появления на экране первой страницы загружаемого документа и высвечивания в статусной строке последней его страницы. Исключение — KWord, для которого реально возможно оказалось измерить только время до появления первой страницы (прошу обратить на это внимание — мы еще вернёмся к этому вопросу).

Разумеется, я прекрасно понимаю условность подобных измерений (что частично компенсировалось троекратным повторением выполнения каждой команды, в том числе, для OOWriter’а — раздельно для запуска в том же сеансе и после перезагрузки), и их нельзя рассматривать как количественные показатели (почему в настоящем материале и не будет никаких диаграмм). Однако качественно картина оказалась весьма отчетливой, и мы это сейчас увидим невооруженным глазом (табл. 2).

Табл. 2. Скорость старта текстовых редакторов со считыванием файлов, различных по размеру и формату

Процессор/Файл OOWriter (1) OOWriter (2) KWord Abiword
unix_all.doc 9,8 5,5 >> 12 24,0
unix_all.odt 9,4 3,5 >> 19 23,9
unix_intro.doc 7,2 1,9 2,6 1,6
unix_intro.odt 7,2 1,8 2,1 1,6
unix_all.abw 24,1
unix_intro.abw 1,4

Примечания:
OOWriter (1) — первый запуск команд в данном сеансе, после рестарта системы, OOWriter (2) — повторный запуск команды в том же сеансе;
KWord >> ## — время до появления на экране первой страницы, время окончательного считывания файла много больше;
Abiword, *.abw — результаты по считыванию файлов в его родном формате, нормально не понимаемом больше никем.

Неожиданные результаты, не так ли? Легендарно-неторопливый OOWriter даже при «чистом» старте на считывании больших файлов обоих форматов оказывается вдвое быстрее столь же легендарно-стремительного Abiword’а. И при повторном запуске OOWriter в том же сеансе разница эта возрастает, тогда как для Abiword’а разницы в скорости между первым и последующими запусками нет (как и для KWord’а, почему эти данные в таблице и не приведены).

Но, может быть, Abiword просто не любит чужих форматов, а уж в своём собственном проявит себя во всей красе? Ничего подобного, время загрузки файла unix_all.abw (того самого, что тянет на 5,2 Мбайт) составляет примерно те же самые 24 секунды…

Хорошо, а не подтвердит ли медлительность OOWriter’а текстовый процессор из KOffice? Казалось бы, для большого файла его показатели выглядят сопоставимыми с таковыми OOWriter’а при первом его первом запуске. Однако вспомним, что в случае с KWord’ом замерить удалось только время появления первой страницы документа. Окончательное же его считывание длилось столь долго, что у меня просто не хватило терпения его измерить; во всяком случае, оно далеко переваливает за минуту, что лишает смысла сравнение по этому показателю.

Результаты по считыванию маленьких файлов, с учетом невысокой точности измерений, можно считать примерно одинаковыми — по крайней мере, они выглядят таковыми в человеческом восприятии. Исключение — OOWriter при первом запуске в сеансе: тут показатели оказываются мало зависящими от размера считываемого файла (почему — мы узнаем чуть позже).

Вообще, для меня оказалось неожиданным, что скорость считывания документа при прочих равных условиях в любом из «подопытных кроликов» практически не зависит от его формата. И это при том, что оба doc-файла, большой и маленький, в 4-5 раз больше соответствующих файлов ODT, а большой abw-файл вообще бьет все рекорды «упитанности».

Чтобы окончательно интерпретировать результаты из табл. 2, в тех же условиях были выполнены и замеры времени старта «голых» текстовых процессоров, без считывания какого-либо файла.

Табл. 3. Скорость запуска «голых» подопытных процессоров

Текст-процессор OOWriter (1) OOWriter (2) KWord Abiword
Время старта 7,1 1,8 1,8 1,1

Примечание: OOWriter (1) и OOWriter (2) — см. прим. к табл. 2.

Можно видеть, что скорость запуска «голого» OOWriter практически равна таковой при считывании маленького файла, повторный же запуск можно считать практически мгновенным. «Голый» Abiword стартует, если так можно выразиться, еще мгновенней, хотя разница пренебрежимо мала. А вот KWord ничем не поражает воображение.

Из сопоставления данных, приведенных в табл. 2 и 3, можно сделать вывод, что при первом старте OOWriter в любых условиях львиную долю времени съедает собственно его загрузка, после чего соответствующие данные (библиотеки и прочее) кэшируются, и все последующие запуски этого процессора происходят намного быстрее, даже при загрузке файлов большого объема.

Abiword, вполне оправдывая свою репутацию «быстрого» при работе с маленькими документами, начинает заметно притормаживать в случае обработки документов больших (независимо от их формата). KWord не демонстрирует рекордов на маленьких файлах, где эти рекорды, впрочем, и не нужны при современных вычислительных мощностях. Но вот на файлах больших о его быстродействии просто не приходится говорить ввиду полного отсутствия оного.

Окончательные выводы вполне очевидны, так что остановлюсь на них лишь вкратце:

  • для всамделишней работы с большими и сложными документами, вне зависимости от среды обитания, альтернативы OOWriter’у с точки зрения быстродействия не просматривается (если, конечно, эту работу хочется и можется выполнять именно средствами текстового процессора); и тут уж придётся мириться со всем тем, что устанавливается вместе с ним в составе офисного пакета;
  • для эпизодической работы с не очень объемными материалами вполне пригоден Abiword — особенно в системах с определяющей ролью Gtk-приложений;
  • использование KWord’а выглядит оправданным только в чистых KDE-системах, да и то лишь в том случае, если текстовый процессор не является критически важным для работы приложением.

Главный же вывод таков: не стоит всегда свято верить вековым легендам, основанным на ощущениях давно забытых дней; неплохо иногда чуть-чуть и померить — и не то, о чём подумали в меру испорченные люди…