Есть ещё вопрос по поводу оптимизации работы с большими файлами,

понятно что с нативными форматами он работает шустрее. но как правило при открытии большого текстового (перегруженного файла) или таблицаы (особенно с вшенними ссылками, и обильным количеством листов и формул) наблюдается подвисание "намертво" или надолго и потом не очень комфортная работа.
Иногда можно ткнуть по несколько раз в файл (в итоге пораждается куча процессов запуска этого файла) и оно ещё больше тормозит.
Можно ли этот момент как-то обойти или сгладить, какие-то рекомендации или best practice работы с LO?

Версия офиса?

Если версия офиса свежая, типа 7.3.3, то только писать баг репорты. Или внимательно посмотреть на файл, возможно в нем есть лишнее и много. Я в свое время нашел в рабочем файле 90000 никому не нужных ячеек, в каждой из которых была тяжёлая формула, которая считала всего навсего номер недели . И это все пересчитывалось на каждый чих

7.1,7,2

Предлагаю или обновить или хотя бы портативку на твоих файлах попробовать

да, такие случаи известны даже в MSO удаление мусора неявного (даже утилита или средствами ПО было) и явного, по примеру Вашего. Но тут глобальный вопрос по выбору ПО для организации как основного. В рамках импортозамещения (LO тут как часть AltLinux рассматривается) а как следует оттестировать на наших задачах не представляется возможным. Хотя даже сейчас есть некоторые моменты которые решаемы, но опять же по информации от сторонних людей о зависающих таблицах, потери данных в документах, я как-то смотрю на это ПО с сомнением, хотя сам использовал ранее, и использую сейчас. Однако мои задачи достаточно просты чтобы покрыть тестирование всех кейсов организации. Мой офис - не покрывают даже моих задач. P7 - тоже странный, но до LO в плане функций и фич ему далеко.

Добро пожаловать в реальный мир

Ну так для применения в реальном мире и нужно руководствоваться best practice внедрений... Отсюда и вопросы..

Производительность в ЛибреОфис - это оптимизировать исходный код чаще всего. Желаете писать патчи?

В p10 LibreOffice-7.3.2.1-alt3

Не знаю на сколько это лучшая практика, но у ООН была брошюра по переходу на открытый стандарт документов и на Хабре была старая статья по совместимому форматированию текстовых док-во. Возможно, в странах официально перешедших на открытый стандарт документов могут быть методички. Замечу, что проблемы совместимости при переходе с мелких и мягких ещё возникает из-за принципа "embrace, extend, exterminate". Потестил. Во время открытия документа не смотря на работу в 13 потоках по факту все операции происходят последовательно. Эта практика отчасти поддерживается в документации по разработке, которая настаивает на не использовании асинхронных интерфейсов UNO. Замечу, многие пакеты открытого ПО плохо управляют памятью, поэтому ИМХО экономить от затрат на лицензию следует вводить в дополнительную производительную оперативную память (чипы Samsung, некоторые hynix, Phillips, micron). В частности, при запуске у меня LO примерно погладил 160мб, при открытии rtf файла с зак.актом медленно погладил около 330мб, но не смог использовать при этом более 25% красного процессора, далее на стадии загрузки документа и при его отображении была около нулевая загрузка ЦП, постоянные фризы приложения и память медленно подросла до 450мб (вероятно происходила не эффективная инициализация загруженных объектов, сервисов, ресурсов). (Ещё можно сделать ряд замечаний по архитектуре...)

Ты патч хотел запилить? Бросил?😊

Пока бросил.

Жаль😔