CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
17.09.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Приложения

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

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

С давних пор среди линуксоидов бытует легенда, что 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 для проекта Zenwalk: пакеты недели, я снова наткнулся на определения этого текстового процессора как легкого и быстрого. Против первого эпитета никаких возражений не возникало — особенно в сравнении с 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-системах, да и то лишь в том случае, если текстовый процессор не является критически важным для работы приложением.

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




Комментарии

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: следующая

Vitaliy, Mon Sep 1 00:37:15 2008:
to В.А.
> Когда дорога -- это размытые дождём глиняные ухабы, вихляющие каждые 10 метров, то даже на уазике быстрее 40 км/ч ехать физически невозможно.

абсолютно согласен - всему есть предел. Вот только дело в том что если один водитель и сможет проехать на уазике около со скоростью 40км/ч, то второй может "улететь" в кювет и при 20км/ч, а третий счастливый обладатель низкопосаженого Порше вообще не сунется на такую дорогу.
Но дело даже не в этом, в любом случае один из этих трех водителей, не зависимо от того какая дорога и авто, хотел бы добраться до пункта назначения как можно быстрее, поэтому и транспорт должен выбирать в зависимости от условий и своих возможностей. Аналогичным образом стоит выбирать и текстовый процессор.
А вот Иван Федоров считает что слишком эффективная работа с документами может вызвать подозрения начальства и навредить здоровью.
В.А., Sun Aug 31 22:34:31 2008:
To: Vitaliy, воскресенье, 31 августа 2008 г. 20:54:07:
> кроме этого скорость ещё определяется автомобилем(на хамере можно лихо гасать даже по русским дорогам) и главное - умением водить(опытный водитель сможет на большей скорости обходить все дыры). Так что сравнение не совсем удачное.

--Нельзя. Когда дорога -- это размытые дождём глиняные ухабы, вихляющие каждые 10 метров, то даже на уазике быстрее 40 км/ч ехать физически невозможно. Лихачей, думающих иначе, я неоднократно наблюдал в кювете. Да и сплошные рытвины при расстоянии между ними не более 30 см во всех направлениях объехать невозможно.

Так что сравнение вполне удачное. Тонкое место в системе человек-механизм обычно человек.
Vitaliy, Sun Aug 31 20:54:07 2008:
to Иван Федоров
>Когда Вы едете по российской дороге, то будь Вы на Porshe, будь Вы на Дэу, скорость определяется дорогой

кроме этого скорость ещё определяется автомобилем(на хамере можно лихо гасать даже по русским дорогам) и главное - умением водить(опытный водитель сможет на большей скорости обходить все дыры). Так что сравнение не совсем удачное.
Вообще-то если вы часто работаете за компьютером то должны были заметить что в системе человек-комп часто из-за технических особенностей именно компьютер работает медленее чем надо, иначе зачем бы автору понадобилось бы сидеть за компом с секундомером. Кроме того программа должна быть достаточно функциональной и эргономичной чтобы работа была более оптимальной и удобной.
Вывод: быстрая работа это очень хорошо. А злое начальство и здоровье это совсем другая тема.
аноним, Sat Aug 30 22:45:02 2008:
Лучше ТеХ использовать
Иван Федоров, Sat Aug 30 21:14:41 2008:
Vitaliю.
Уважаемый Vitaliy! Когда Вы едете по российской дороге, то будь Вы на Porshe, будь Вы на Дэу, скороть определяется дорогой (ударение на втором слоге) и Вашей машиной. Но ведь никто не называет Вас тормозом, если дорога в дырах. Скорость определяется дырами. Life is life.
Когда имеется система из человека и ЭВМ (компьютера), то любая часть такой системы, если она работает медленно, определяет процесс в его скорости. Если Ваша личная работа рассчитывается с точностью до долей секунды, то тогда тормоз - компьютер. Но вероятнее всего, из двоих - компьютера и человека - тормозом является человек.
Так что либо мы с Вами тормоза, либо нет.
Vitaliy, Sat Aug 30 16:40:14 2008:
2 Иван Федоров
Извините, а вам не кажется что вы просто тормоз. Иначе как объяснить то что эффективность программы вы относите к недостаткам.
Иван Федоров, Sat Aug 30 10:14:27 2008:
Как типичный первопечатник, приведу басню из журнала "Крокодил" советских времен.
Два мужика (в смысле - не женщины) стоят два часа в кафе и пьют кофе (дело происходит в Западной Европе; у нас это будет водка). И неспеша спорят о том, чем быстрее бриться.
Один говорит, что бреется электрической бритвой за 5 минут. Другой говорит, что бреется безопасной бритвой за 15 минут.

Я предпочитаю работать с помощью клавиатуры. Экономлю время по сравнению с вариантом, когда используется преимущественно мышка. Работал в MS Word, OOWriter, Abiword.
Больше всего встроенных команд в MS Word. В OOWriter те же команды при их отсутствии могут быть дописаны как макросы (лень заниматься). Но основной набор клавиатурных команд в OOWriter присутствует на горячих клавишах, как и в MS Word.

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

Выводы:
1. Не всегда высокая скорость работы - хорошо. Особенно когда человек перестает замечать переутомление, потому что увлекается высоким ритмом работы.
2. Как бы скорострельно не работал текстовый процессор, всегда нужно помнить о здоровье, которое с возрастом не улучшается.
аноним, Fri Aug 29 21:08:12 2008:
"для эпизодической работы с не очень объемными материалами вполне пригоден Abiword — особенно в системах с определяющей ролью Gtk-приложений;"
---
Купил eeePC. Ставить на него OO.org - значит зря расходовать 4Гб диска. Лучший выход - AbiWord. Так, к слову.
Алексей Федорчук, Fri Aug 29 20:40:54 2008:
2 fyjybv
Спасибо, обязательно протестирую при следующем тестировании :)
Кстати, это ведь очень важный тест - какие слова более будут способствовать точности и воспроизводимости измерений?
fyjybv, Fri Aug 29 19:07:08 2008:
Алексей Федорчук, пятница, 29 августа 2008 г. 14:51:00:
2 Alex
Вы безусловно правы!
А начало и конец отсчёта надо фиксировать сакраментальным русским: "Б...дь!"
--------------
Позвольте поправить. Старт лучше обозначать не менее сакраментальным : "Х@як!", или чем-то в этом роде, а финиш - "П..дец!" :)

Страницы комментариев: предыдущая :: 1 :: 2 :: 3 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds