Ускорение установки LibreOffice на macOS

Установка LibreOffice в macOS меня всегда раздражала своей медлительностью, даже если macOS установлена на SSD. Как оказалось дело было в том, что LibreOffice упаковывался в DMG образ, используя старинный bzip2 архиватор.

Наконец-то нашелся хороший человек, который это изменил. Patrick Luby написал патч, который изменил использование bzip2 на lzfse. 

Это должно увеличить скорость установки LibreOffice в macOS раз в пять, если я правильно понял сообщение Patrick'a в патче.

Изменение уже будет доступно в следующем минорном обновлении LibreOffice 7.4.4 и конечно в грядущем 7.5.

PS: я попробовал установку с этим патчем - просто очень быстро все прошло, по сравнению с тилипанием без патча!

Luboš Luňák решил проблему с производительностью функций ВПР, СУММЕСЛИ и СЧËТЕСЛИ в LibreOffice Calc

Разработчик из Collabora Luboš Luňák решил наконец проблему с производительностью в LibreOffice Calc функций ВПР, СУММЕСЛИ и СЧËТЕСЛИ при работе с бльшими обьемами данных. О чём и написал в своём блоге минизаметку.

 

Данные выше (слева время работы функций до патчей, справа после патчей) - это какие-то пользовательские файлы от компании SuSe. Сами видите, насколько стало всё быстрее.

Фокус был в том, что если данные для функции ВПР отсортированы, то LibreOffice Calc применял для поиска в данных бинарный поиск, а если данные не отсортированы, то линейный, когда проверяется КАЖДЫЙ элемент. Представьте, если у вас десятки тысяч элементов надо перебрать. Решением стало копирование не отсортированных данных в память, их сортировка, кэшировние, а затем приминение к результату всё того же бинарного поиска. На словах всё вроде просто, а решение по факту заняло очень много времени.

Это улучшение будет доступно уже в LibreOffice Calc 7.4, который выйдет в августе 2022 года. Спасибо Luboš Luňák за эту работу.

Ускорение экспорта документов в формат PDF

Luboš Luňák отчитался в своем блоге о проделанной работе по ускорению экспорта файлов из LibreOffice в формат PDF. По его словам ускорение некоторых внутренних операция во время экспорта после его патчей достигает до 62 раз! Это весьма круто. Проверял он на каком-то огромном 400 страничном документе. Ну и кстати, это говорит о том, что исходный код LibreOffice весьма неоптимален в некоторых местах, а также о том, что Luboš крутой перец =)

Какой же LibreOffice процессорозависимый или как я офигел от процессора Apple M1

Вздумалось мне попроверять старые баг репорты про производительность LibreOffice Calc. Ну где-то есть прогресс, где-то нет, суть не в этом. И вспомнил я, что у знакомых ребят есть на руках ноутбуки macbook с процессорами Apple Silicon M1, про которые легенды ходють.

Ну что сказать, легенды оказались вовсе не легендами. Пара примеров ниже:

1. Баг репорт tdf#125254 - проблема в долгом открытии файла (там куча тяжелых формул внутри и вес более 18 мегабайт).

Apple М1 в LibreOffice 7.3 beta 1 для ARM - открыл за 18 секунд

AMD Ryzen 5 5500 U в LibreOffice 7.3 beta 1 - открыл за 40 секунд

Intel Core 2 Quad 9450 (это мой) в LibreOffice 7.4 alpha 0 - открыл за 2 минуты 10 секунд

2. Баг репорт tdf#119083 - проблема в долгой вставке столбца, если в файле используется огромное количество формул с функцией ВПР.

Apple М1 в LibreOffice 7.3 beta 1 для ARM - вставил за 15 секунд

AMD Ryzen 5 5500 U в LibreOffice 7.3 beta 1 - вставил за 1 минуту 06 секунд

Intel Core 2 Quad 9450 (это мой) в LibreOffice 7.4 alpha 0 - вставил за 3 минуты 30 секунд

То есть я, имея самую распоследнюю версию LibreOffice, со всеми возможными оптимизациями, но имея древний процессор, я в этом соревновании проиграл и как проиграл! Примерно в ТРИ раза ноутбучному АМД (правда это самый распоследний АМД, доступный сейчас).

А поглядите на М1 от Apple! Это что-то НЕВЕРОЯТНОЕ в плане скорости. В ЧЕТЫРНАДЦАТЬ РАЗ быстрее моего древнего процессора во втором баг репорте и в ПЯТЬ раз быстрее современного ему процессора от АМД!

А ведь проверяли мы крайне тяжелые случаи, эти вещи по идее можно оптимизровать, переписав исходный код в LibreOffice и тогда М1 вообще будет "моментальность"!

Проблемы с производительностью LibreOffice Calc на примере функции VLOOKUP (ВПР)

Печальный пост будет. При разгребании баг репортов в нашей багзилле я наткнулся на проблему, связанную с очень большим временем (минуты!), которое тратит Кальк на вставку формулы, которая содержит функцию VLOOKUP (ВПР), в большое количество ячеек. Также Кальк весьма задумчив, если VLOOKUP имеет в качестве аргумента огромный диапазон для проверки значений (около 100000 записей), и мы заполняем несчастные сто строк такой формулой.

Вот один багрепорт, вот второй.

Ладно, Ноэль попытался что-то сделать с первым, однако общее улучшение не очень значительно, порядка 20% по времени всего. Проблема где-то глубоко внутри LibreOffice Calc, как я понял.

Ради интереса я проверил тот же самый случай в MS Excel. Результат - просто моментальная работа. Ладно, ОК, MS потратило миллиарды баксов на разработку и оптимизацию Excel. Говорят, там внутри давно уже все сделано, как база данных, именно для скорости работы.

Но есть и ещё один софт аналогичного функционала для работы с электронными таблицами и он OpenSourse. Я говорю про Gnumeric.

Я проверил те же проблемы с VLOOKUP (ВПР) в Gnumeric (по счастью он умеет открывать ODS файлы напрямую). Результат - моментальная работа! Не хуже, чем в MS Excel!

Я конечно этой ситуацией опечален. Наличие фундаментальных проблем с производительностью LibreOffice весьма удручает. А ещё больше удручает, что никто не берется туда залезть. Как всегда, нету квалфицированных, заинтересованных кодеров. Тут студент из GSoC программы не справится, тут нужен ОЧЕНЬ грамотный и опытный специалист в С++.

Проблемы со сверхдлинными таблицами в Writer

Подсмотрено на нашем форуме https://forumooo.ru/.

Человек использовал в работе документ Writer на 270 листов, на которых насквозь, через все листы расположена ОДНА гигантская таблица. Это вызывало вылетания LibreOffice.

Ну так вот, не делайте так никогда!

Причиной проблем является следующее (цитата с форума): "Это большая проблема, причём дело не в памяти, а в процессоре. И на 16 ГБ это тоже будет виснуть, потому что при обработке большого цельного объекта таблицы при необходимости разместить его на страницы, к сожалению. алгоритм программы пытается пересчитать размещение начиная с первой строки десятки раз. С увеличением длины таблицы сложность возрастает квадратично." (c) Mike Kaganski

Решение - разделить гигантскую таблицу на несколько. Должно помочь.