LINUX.ORG.RU

Открытому офису добавят прыти

 ,


0

0

Текущая производительность OpenOffice.org не вызывает бурных оваций, поэтому была создана группа, состоящая из разработчиков Sun Microsystems и Beijing Redflag CH2000, для поиска и устранения проблем в производительности.

Вот некоторые результаты работы этой группы: OpenOffice.org Calc теперь загружает тестовые таблицы на 55%-63% быстрее, а потребление памяти сократилось на 75%. Также закрытие большого документа в пакете сократилось с 10 секунд до 1 секунды.

Все эти улучшения ждут проверки на качество и войдут в состав OpenOffice.org 3.2.

Подробнее о проделанной работе для Calc.

Страничка проекта по оптимизации.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от unkn55

> имелось в виду по скорости сохранения по сравнению с Compound Document - надо сформировать полностью файлы на xml, упаковать все данные в зип, полностью перезаписать файл, в Compound - переписывание фрагментов файла

Ю гет зе пойнт. Именно в этом кардинальный недостаток сжатого текста (потока данных). И если на мелких и средних по размерам документах на современой технике принципиальной разницы по скорости для юзера нету, то с большими файлами ситуация весьма и весьма грустная. Потому, что в МСО есть режим ИНКРЕМЕНТНОГО сохранения. Когда не переписываются фрагменты файла, а дописываются в его конец диффы. Размер растёт бешеными темпами, но сохранение хоть гигабайтного документа за доли секунды (буквально! на самой слабой машине, хоть на 386DX, лишь бы документ в принципе открывался) - рулит нипадеццки, мягко говоря. Причём этот недостаток преходящий - однократное сохранение документа с выключенны инкрементным режимом приводит размер в норму.

Mess
()
Ответ на: комментарий от Mess

>Потому, что в МСО есть режим ИНКРЕМЕНТНОГО сохранения. Когда не переписываются фрагменты файла, а дописываются в его конец диффы

а потом секретная информация, вроде-бы удалённая пользователем, оказывается в Интернете- прецеденты были, довольно массово.

ЗЫ
функциональности OO в нашей конторе хватает, интерфейс для типичного манагера тем удобнее, чем он дольше не меняется (мода на новые темы к каждому релизу- ЦЕНЗОРЕД!),
производительность на компьютере, который сейчас можно купить на сэкономленные на МСО деньги- вполне приемлема, (ну пусть это в основном заслуга разработчиков процессоров, а не ОО- не всё ли равно?..)

Anonymous ★★★★★
()
Ответ на: комментарий от Mess

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

это происходит из-за самого зипа

зип основан на алгоритме сжатия Лемпела-Зива со словарем- в упаковываемом потоке ищется наибольшая цепочка находящаяся в словаре и в словарь добавляется указанная цепочка плюс один символ, то есть чем длиннее упаковываемый файл, тем медленнее работает архиватор,

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

поэтому зипованный xml использовать для доков-отстой, ну можно конечно

логичнее было бы хранить какое-нибудь компактное бинарное представление самого xml-a без сжатия с открытым словарем как в зипе

unkn55
()
Ответ на: комментарий от Anonymous

> а потом секретная информация, вроде-бы удалённая пользователем, оказывается в Интернете- прецеденты были, довольно массово.

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

Это беда не формата и возможности, а человеческий фактор. Например, если я напишу и повешу в фон программулинку, которая будет автоматически копировать всю информацию с любой флэшки, вставленной в мой комп, особенно - удалённые файлы, то что? Ты потребуешь запретить USB? Это ж какое нарушение секьюрности-то! Хомячок будет уверен, что когдато записанный и давно стёртый компроментрующий контент (фотки, где он трахает жену босса, база данных, которую переносил с компа на комп и котрая не должна поасть конкурентам, и тыпы), исчез и недоступен, а оно вовсе не так. И что, бороться против флэшек? ФАТа?

Кста, кто подскажет, под никсы тулзовину для вайпа данных, с поддержкой ФАТ (NTFS)?

Mess
()
Ответ на: комментарий от Anonymous

> функциональности OO в нашей конторе хватает, интерфейс для типичного манагера тем удобнее

Ещё раз кстати. Подскажи, есть в калке, и если есть, то как называется и где сидит кнопка, что в экселе зовётся "влияющие ячейки" ("зависимые ячейки")?

Как задать для ввода дефиса сочетание клавиш, удобное мне, например Ctrl+Shift+- ?

Mess
()
Ответ на: комментарий от Mess

> Кста, кто подскажет, под никсы тулзовину для вайпа данных, с поддержкой ФАТ (NTFS)?

Лехко: dd + rm (+sync). dd забиваем всё свободное место на примонтированном разделе нулями, rm'ом созданный файл удаляем. Для самых параноиков в промежутке можно выполнить sync, чтобы быть уверенным, что все нули записались на диск.

Alan_Steel ★★
()
Ответ на: комментарий от Alan_Steel

Тогда уж не dd, а head -c `df /mnt/disk | tail -n 1| awk '{print $4}'` | dev/random > /mnt/disk/fakefile. Но так не интересно. Вопрос был как гарантированно уничтожить один файл, с выносом его следов из файловой системы, а не насиловать весь накопитель.

Mess
()
Ответ на: комментарий от Mess

Извиняюсь, почему-то прочитал в исходном сообщении вопрос о вайпе свободного места. Впрочем, запрашиваемые приблуды тоже есть:

$ apt-cache show secure-delete
Package: secure-delete
Priority: optional
Section: utils
Installed-Size: 140
Maintainer: Robert Lemmen <robertle@semistable.com>
Architecture: i386
Version: 3.1-4
Depends: libc6 (>= 2.7-1)
Filename: pool/main/s/secure-delete/secure-delete_3.1-4_i386.deb
Size: 67022
MD5sum: 2cae0933c51477efdb1ea8e92c82cfdb
SHA1: 49e2130b07f62ac0b857135e9305551aa0ca96d8
SHA256: 8815799fe1fa4023f2ff807f1304aa42de9fa721068fff4030daf583c210395d
Description: tools to wipe files, free disk space, swap and memory
Even if you overwrite a file 10+ times, it can still be recovered. This
package contains tools to securely wipe data from files, free disk space,
swap and memory.
Tag: implemented-in::c, interface::commandline, role::program, scope::utility, security::privacy, works-with::file

apt-cache show wipe
Package: wipe
Priority: extra
Section: utils
Installed-Size: 132
Maintainer: Debian Forensics <forensics-devel@lists.alioth.debian.org>
Architecture: i386
Version: 0.21-6
Depends: libc6 (>= 2.7-1)
Filename: pool/main/w/wipe/wipe_0.21-6_i386.deb
Size: 43588
MD5sum: dcb7c804d429efda2d1f6e2f4a7d9561
SHA1: 05000c1e747a9f26f5122c39d621769a941a6b19
SHA256: c9f598573ebd303e07a961766dfebeb03a7b9ddc0c3ea79f90cc65acc3e8c4e7
Description: Secure file deletion
Recovery of supposedly erased data from magnetic media is easier than what many
people would like to believe. A technique called Magnetic Force Microscopy
(MFM) allows any moderately funded opponent to recover the last two or three
layers of data written to disk. Wipe repeatedly writes special patterns to the
files to be destroyed, using the fsync() call and/or the O_SYNC bit to force
disk access.
Homepage: http://abaababa.ouvaton.org/wipe/
Tag: interface::commandline, role::program, scope::utility, security::privacy, works-with::file

Alan_Steel ★★
()
Ответ на: комментарий от Alan_Steel

Снкс. wipe и secure_delete. Похоже, что именно оно.

Mess
()
Ответ на: комментарий от Mess

>> это происходит из-за самого зипа

>Тип сжатия не принципален, принципиально наличие сжатия.

>Mess (*) (01.05.2009 13:21:40)

архиваторы вроде zip используют растущий в размерах словарь, что отражается на скрости при росте размера Если скажем использовать специальные методы сжатия, напрмер представлять теги xml в компактном виде,не будет так отражаться, к тому же xml как текстовый формат избыточен, тратится время на его генерацию(при записи) и разбор(при чтении)- не самый оптимальный способ представления данных

если сам xml в бинарном виде представить тогда и сжатие внешним архиватором бы не требовалось- также как doc не сжимается никаким зипом

для xml-данных должен быть какой-то свой быстрый алгоритм упаковки

unkn55
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.