Автор Тема: Скорость сохранения файла в Libreoffice  (Прочитано 5973 раз)

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
У меня есть один большой файл - порядка 500 страниц, с диаграммами, таблицами и проч. Скорость сохранения на разных компах отличается очень сильно (на одном - секунд 5, на другом - минута-две). Понятно, что компы отличаются быстродействием, но не настолько же... Чем может быть вызвано такое явление?
« Последнее редактирование: 26.06.2017 20:47:42 от Сергей-70 »

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 908
    • Домашняя страница
    • Email
Размером памяти.
Андрей Черепанов (cas@)

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
Размером памяти.
Поставил на ноут 4 гига планку, разницы не заметил. На ноуте процессор амд у350 (старый). На настольном Intel Core i3-3220
Неужели разница в процессорах так влияет...

Оффлайн Антон Мидюков

  • alt linux team
  • ***
  • Сообщений: 5 183
  • antohami@
Неужели разница в процессорах так влияет...

Ещё как влияет!

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Неужели разница в процессорах так влияет...

Посмотрите :-)
http://www.cpubenchmark.net/compare.php?cmp[]=1777&cmp[]=1472&cmp[]=2484

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
Что я сделал - увеличил память для libreoffice (от балды поставил 600 мб, могу теперь позволить))
Скорость сохранения существенно увеличилась, до приемлемых 15-20 с. Конечно, разница с настольным компом велика, но уже что-то

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
http://www.cpubenchmark.net/compare.php?cmp[]=1777&cmp[]=1472&cmp[]=2484
Оказывается у меня настольный комп хороший ))

« Последнее редактирование: 28.06.2017 09:13:13 от Сергей-70 »

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
http://www.cpubenchmark.net/compare.php?cmp[]=1777&cmp[]=1472&cmp[]=2484
Оказывается у меня настольный комп хороший ))

Щас охлажу :-)
http://www.cpubenchmark.net/compare.php?cmp[]=2792&cmp[]=1472

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
Щас охлажу
Код: [Выделить]
http://www.cpubenchmark.net/compare.php?cmp[]=2792&cmp[]=1472
Жуть)))
Правда такая мелочь: производительность выше в 5 раз, а цена в 15)))

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Щас охлажу
http://www.cpubenchmark.net/compare.php?cmp[]=2792&cmp[]=1472
Жуть)))
Правда такая мелочь: производительность выше в 5 раз, а цена в 15)))

:-) Тут есть масса всяких но:
Ну так сегодня весь софт пишется под мощное или относительно мощное железо, и сегодня, принципиальной разницы между Linux и Windows я уже не вижу. С учётом того, что на мой личный взгляд, только одного из ста программистов можно назвать квалифицированным. В общем сегодня на Линукс, всё приблизительно так же как и на Windows:  хотите жить спокойно, вытряхивайте бабки на новое железо и будет вам счастье.  У меня например Линукс прошёл по железу от i386 до LGA1155 и LGA1151 и в этом плане, лично для меня, ничего не изменилось. И сколько этих пачек долларов было вытряхнуто на новое железо, я себе даже приблизительно не представляю.
В плане же старого железа?, - на ICH6 вынужден был дорастить память до 2Gb с помощью китайской торговой площадки, а процессор с достаточных когда-то 1733MHz до минимальных сейчас 2133MHz. И это только при переезде с бранча на бранч. Кстати это неплохой вариант апгрейда и железо вам может обойтись вдвое, а то и втрое дешевле, чем на местных рынках, но вы же понимаете, что всё движется "вперёд". (Теоретически можно дорастить до 2.26GHz, но потребуется сделать downvoltage, который на Линукс, полный вынос мозга, в отличие от FreeBSD кстати.) Правда можно оставаться и на старом репозитории, но придётся мириться с дырявостью Линукс, - обновления безопасности никто не отменял, ни в Windows, ни в Linux. Да и вообще нигде. Конечно же всё это имхо.

Хотите больше практики, а не теории?, - да пожалуйста.
Браузер с четырьмя вкладками плюс терминал:
$ free -m
             total       used       free     shared    buffers     cached
Mem:          2012        789       1222          0         51        467
-/+ buffers/cache:        270       1742
Swap:         2311          0       2311

Но учтите, что здесь запущены newmoon и терминал на Intel графике. 270 метров это в принципе и немного по сегодняшним временам. С nVidia добавьте сюда ещё метров 250 (плюс-минус). Кеш почти 500 метров?, - ну а как же без него, - доступ к дисковой памяти самый медленный. И того, без копеек, занято почти 800 метров. 200 свободных метров при километровой памяти, это вообще ничего. Да у вас там есть своп и всякое такое, но свопа вы должны избегать всеми доступными вам средствами. Свопинг это крайний случай и от него нужно срочно избавляться. И того к этому гигабайту добавляем метров пятьсот, а лучше гиг:  в зависимости от программы, потребление памяти может быть очень разным. При этом заметьте, что ни о какой мультисессионности здесь речь даже не идёт: как только used+cache достигнут порядка 90%, вы получите в Линукс жесточайшие тормоза. При этом добавьте сюда ещё и просадку в производительности процессора и всё станет ещё хуже. А его производительность временами зависит от I/O, которую иногда можно сравнить с автобаном в часы пик. И это можно считать минимально приличной конфигурацией. При этом заметьте, что никаким KDE здесь и близко не пахнет. Теоретически систему можно ещё больше оптимизировать. Но только теоретически. Поскольку можно где-то и как-то столкнуться с ужасным количеством багов и когда или в каком десятилетии они будут исправлены вам вряд ли кто скажет.
Всё это не истина в последней инстанции, - это только личный взгляд на текущее положение дел в Линукс.
« Последнее редактирование: 01.07.2017 02:40:07 от Speccyfighter »

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
Re: Скорость сохранения файла в Libreoffice
« Ответ #10 : 01.07.2017 21:54:52 »
Мне тоже не нравится тенденция с утяжелением софта. Если не брать в рассчет обработку тяжелых данных (видео, как правило), то большую часть задач можно решать легкими альтернативами, как правило, текстовыми.
Например, те же тексты можно на языках разметки делать и конвертировать в офисные форматы с помощью pandoc. Ну или в формате tex.
Вот кстасти, вопрос специалистам в libreoffice - с точки зрения скорости работы как лучше делать диаграммы - встроенными средствами офиса или делать другими инструментами, например, gnuplot и вставлять картинки в текст?
Поясню сразу, откуда вопрос - некоторые вещи с диаграммами встроенными средствами libreoffice я сделать не смог, поэтому учил gnuplot, ну и потом им удобно - файлы с данными по мере необходимости править - и диаграммки быстро перерисовывать, а не тащить все данные в один файл.

И еще вопрос - в настроках памяти libreoffice есть пункт "количество памяти на объект" - что за объекты имеются ввиду?

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Re: Скорость сохранения файла в Libreoffice
« Ответ #11 : 02.07.2017 02:42:47 »
в настроках памяти libreoffice есть пункт "количество памяти на объект" - что за объекты имеются ввиду?

https://help.libreoffice.org/3.5/Common/Memory/ru
У более свежей версии перевод не полный.

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
Re: Скорость сохранения файла в Libreoffice
« Ответ #12 : 02.07.2017 12:02:08 »
О, спасибо)). Как я понял, нужнго оценить суммарный объем используемых в тексте картинок и исходя из этого устанавливать используемый объем памяти. Если ole не используются - то и не выделять им ничего
Вот еще что ускоряет офис:
Хорошо помогает отключение автопроверки орфографии и переключение отображения текста в режим "веб-страница"

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Re: Скорость сохранения файла в Libreoffice
« Ответ #13 : 02.07.2017 12:42:23 »
О, спасибо)). Как я понял, нужнго оценить суммарный объем используемых в тексте картинок и исходя из этого устанавливать используемый объем памяти.

Там ключевое:
Памяти на объект (МБ)

Сначала писатель собравшийся набрать книгу в либреофисе должен изучить что такое байты/килобайты/мегабайты. Затем, что такое объекты. Если он к этому времени не пошлёт разработчика вместе с его текстовым процессором, выяснить максимальный размер самого большого объекта и выставить чуть больший объём кратный мегабайту. Либо указать заведомо больший.

И там перевод не скажу через что.
Оригинал:
Памяти на объект (МБ)
Specifies that objects which are larger than the selected megabytes will not be placed in the cache.

При переводе документации с английского на русский вольности не допустимы:
По русской ссылке перевод с отсебятиной:
Памяти на объект (МБ)
Указывает, что объекты, размер которых в мегабайтах превышает указанный, сохраняться в кэше не будут.

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

Specifies that objects (указавает что объекты) which are larger (которые больше) than the selected megabytes (чем выбранные мегабайты) will not be (не будут) placed in the cache (помещены в кеш).
« Последнее редактирование: 02.07.2017 12:59:55 от Speccyfighter »

Оффлайн Сергей-70

  • Давно тут
  • **
  • Сообщений: 496
Re: Скорость сохранения файла в Libreoffice
« Ответ #14 : 02.07.2017 20:11:02 »
Вот по поводу объектов возник такой вопрос: я делаю диаграммы в gnuplot в формате svg. Этот формат векторный и хорошо понимается либрой. Но после вставки диаграммы в текст в сохраненном файле хранятся и изображения svg и png. Причем png многократно (что естественно) превышают исходные векторные картинки. Как я понимаю, программисты чтобы ускорить работу редактора просто ковертируют соответствующую диаграмму в png нужного размера. Таким образом, мне нужно ориентироваться не на исходный вес  svg, а на преобразованные в png картинки, так?