ребят, по каким объективным причинам можно чай не спеша попить и сигарету выкурить пока он запускается? какие у него объективные и не преодолимые тормоза(из-за чего конкретно)?
wsd используйте сборку от русских фирм(i-rs.ru). такой опенофис так же бесплатный, но на слабых машинах тормазов не замечено
В нашем универе он стоит на довольно слабых компах. И тормазит. А всё потому, что бабушке-админу не докажешь что 300мб файла подкачки(при 128 оперативки) мало для работы анвируса в купе с кучей других программ в фоновом режиме. И сообщение о том, что виртуальная память заканчивается, при старте обычного калькулятора она не замечает, видимо, в силу своего возраста. Излил душу
+ еще нужно использовать быстрый запуск, дабы каждый раз либы по новой не загружать, да инициализацию проводить
ОпенОфис тормозит всегда и везде по сравнению с мелкомягким (2003, во всяком случае). Особо жуткие тормоза -- на проверке орфографии. Ну и плюс постоянные глюки, неудобство в работе... Полгода с ним мучился, даже более-менее привык, но когда он в очередной раз покалечил мне документ (у меня постоянно используется сложное оформление и т.п. вещи), я всё же снёс его и вернулся к Офису 2003. Будем ждать версию 3
тормоза скорее всего от dll-ок Динамически подключаемые библиотеки - изначально порочная система... её придумали, когда оперативной памяти было маловато, а захотелось реализовать многозадачность. мне кажется так, может и неправ...
Однозначно неправ К многозадачности никакого отношения они не имеют. Вот к экономии памяти -- да, имеют, поскольку позволяют использовать одну копию библиотеки для многих задач сразу. Точнее, в теории позволяют, на практике же зависит от кривизны реализации. Сама идея отнюдь не нова. Например, ещё в OS/360 (середина 1960-х) загрузочные модули подгружались по мере необходимости из файлов библиотек, вызывали друг друга, использовались несколькими задачами сразу и т.д. Сама идея не является порочной, порочна практика использовать DLL когда надо и когда не надо. Например, вынос часто используемых общих функций в отдельную динамическую библиотеку (типа user32 в Винде) -- совершенно правильное решение. Такая библиотека загружается в память фактически один раз и остаётся там всё время работы системы, что экономит физическую память и ускоряет загрузку (да и работу) приложений. А вот дробление одной программы на множество мелких модулей, которые никому, кроме этой программы, больше и не нужны, является обычно вредным.
Сложно сказать почему у ТС тормозит. Венда она вообще непредсказуемая система, тормозить может в самые неожиданные моменты. У меня полгода назад на pIII 1GHz + 512Mb запускался пристойно. То есть неспешно, но на то, чтобы найти в бардаке на столе пачку сигарет, зажигалку и прикурить, времени не всегда хватало. Как я понимаю, всё зависело от степени забитости оперативки. Сейчас я его регулярно запускаю на Athlon 3200+ (64bit сборка), P4 HT ~3ГГц, P4 1.4ГГц 256Mb, причём последний, кроме всего прочего, не моя сборка и на венде. Никаких тормозов нету вообще. Может он работает и медленнее чем MSO2003, но на глаз этого незаметно. Быть может потому, что последняя конфигурация целиком в моей юрисдикции, и там работают только проверенные личности, соответственно ничего лишнего (типа антивирусов, груды ненужного софта в автозапуске...) там нету. Но замечу, при этом, что OO вообще-то крайне неприязненно относится к оптимизациям. Базовые оптимизации -O2 он ещё переживает, но какая-нибудь глупость типа -ftracer или -finline-functions приводит к тому, что сборка завершается с ошибкой. masm32 Не надо так. Если отказаться от динамических библиотек, то мало тех геморроев, которые будут возникать при пересборке какой-нибудь библиотеки -- это же всю систему придётся из-за неё собирать... Мало того, что места на диске вся система будет занимать раз в несколько больше. Так ведь ещё и гигабайта оперативки будет мало для посредственного десктопа.
Может быть для самой оси применение динамических библиотек оправдано - у приложений появляется возможность их использовать, но убедился неоднократно, что программы которые почти всё носят с собой хотя и больше по размеру, работаю быстрее намного - например KMPlayer, Acronis и т.д. Однако - OppenOffis как раз и не использует виндовские библиотеки - он же должен быть open. Тут дело в другом - опенсурсники, как известно, большие любители пива и, соответственно, - большие чудаки. Им даже не приходит в голову, что не все юзеры имеют возможность апгрейдить компутер раз в месяц, а раз в полгода - менять его на последню самую навороченную модель. Если не лень - посмотрите сколько dll-ок OppenOffis загружает при открытии - штук 40...
masm32 Ну, мне это напоминает уже упомянутую мной OS/360 Система проектировалась для работы на очень широком спектре конфигураций, где объём памяти мог варьироваться от 64 Кб до 16 Мб, и поэтому была сделана жутко модульной -- тысячи модулей, в основном малого размера (минимальный -- 8 байт кода )) , ну а средний -- где-то с полкило). Есно, работало всё это жутко медленно, поскольку ось постоянно свои кишки грузила с диска (а диски тогда были немножко помедленнее, чем сейчас -- 156 и 312 Кб/с у большинства моделей при времени позиционирования с дорожки на дорожку до 10 мс). Но зато можно было большинство модулей объявить резидентными в памяти, если её объём был достаточный: и тогда система работала очень даже шустро. В общем, похоже, что авторы опенофиса хотели как лучше, ну а получили... Нельзя доводить идею до абсурда, а 40 ДЛЛ для текстового редактора -- это полный бред.
