Скорость открытия файла.

[Massaraksh7]

А вот здесь ожидало разочарование. Для особенно громоздких форм думал сделать формирование на html, а потом загружать в Calc (как сейчас делаю на Excel). Проверил на среднем типовом журнале работ: html-файл ~15Mb.
Если в Excel он загружается ~9 секунд (и то пользователи ворчат), то в Calc ~ в три раза дольше.

[Massaraksh7]

Пример такого файла (порезана шапка и исполнители).
А вот плюс то, что формулы в html-файле Calc понимает.

[Massaraksh7]

И попробовал через "Мост" то же самое:
Таблица 9064 x 27
Запись данных через массив - 245000 чисел - около секунды
Бордер на всю таблицу - меньше секунды
Объединение ячеек ~9000 областей ~26 секунд
Итого - то же на то же, около 28 секунд, причём львиная доля на объединение ячеек.
И, что характерно, когда я это делал в режиме видимости, там внизу мелькало сообщение, что-то типа "Автоподстройка высоты строки". Но мне, в данном случае, не нужно её подстраивать. Как это можно исключить? Может, удастся сократить время до разумных пределов...

[Massaraksh7]

P.S.: Использовал shrinkToFit = False - не помогло

[economist]

Calc довольно быстро (не уступая Excel) работает с чистыми TXT/CSV, но на "средних" данных он быстро начинает грустить (вместе с аналитиком). Когда-то сам наивно полагал что BI можно запилить целиком в эл. таблицах, уж больно нагляден и привычен этот класс ПО. Но повторимость шагов плохо ложилась в макросы, глюки, подвисы и монопольность доступа свели радость на нет. Классические же решения со "строковыми" SQL СУБД оказались медленными на сложные агрегации, трех-этажные SQL с джойнами и оконными ф-ми простой офисный люд невзлюбил. Внезапно выстрелили "колоночные" БД и сериализованные хранилища, которые и в виде файла, и в RAM оказались кратно быстрее. 

Начал искать самый быстрый способ обновлять в 10 млн строк по 0,3 млн., каждый час, из разных учетных программ, API-сервисов, логов, IoT-сенсоров, и отражать их в табличные отчеты (через агрегации, конечно) по этой "базе" во Writer/Word/Calc/Excel и веб-приложениях с сотнями-тысячами строк, графиками итп BI. Рисерч был на пару месяцев, опробовано кмк все имевшееся на рынке, не буду утомлять числами.

Победил формат TXT/CSV (экспорт в него поддерживают все виды делового ПО), даже с нарушением спек, безумными смесями кодировок, обрывами строк, непарными ограничителями текста и т.п. "подарками" от 1С-погромистов засыпающих лицом на клавиатуре операторов.

TXT/CSV оказался самым "грязным" из сырых/возможных, но пошагово стабильно очищаемым форматом, который в итоге кладется в "колоночный" формат Apache Feather или DuckDB посредством кросс-платформенного Pandas/Polars/JupyterLab в Python из состава LibreOffice и становится виден в LO Base (а значит и по Ctrl+Shift+F4 во всех приложениях, включая Draw и Impress). Да, внезапно самообновляемые слайды с DDE-мини-табличками из Calc и из Base стали ежедневным инструментом.

В современной информатике такое называется "Аналитической базой данных", которая:
- содержит "причесанные" данные, которым можно безоговорочно верить (включая ML-предсказания)
- полностью перезаписывается условно каждый час (оркестратором или планировщиком)
- способна менять "правила игры" на ходу, по всем периодам сразу
- работает быстрее всего что есть на свете, так как висит в RAM (на АРМ или на сервере), отъедая там почти все место. В LO попадают только агрегации, "хвосты" и единичные значения, а значит торможений нет

Если взять общее время (выгрузка из стороннего ПО, очистка, сжатие - "сбор") и получение отчетов SQL или df.query()-запросах в Pandas с отражением в LO - "отчет") - то оба этих процесса примерно в 4 раза быстрее всех прочих опробованных способов.

HTML-формат тоже есть во многих видах делового ПО, но для быстрого парсинга он подходит плохо. Также ждало разочарование с почти мгновенным парсингом XML/JSON на С++/Rust/Go-либах - нечитаемость глазами этих форматов вылезет боком, когда что-то ломается в строках (а оно на бух-данных ломается часто).

[Massaraksh7]

Спасибо за такой развёрнутый обзор. Буду думать и пробовать.

[sokol92]

, что характерно, когда я это делал в режиме видимости, там внизу мелькало сообщение, что-то типа "Автоподстройка высоты строки". Но мне, в данном случае, не нужно её подстраивать. Как это можно исключить?

Попробуйте такой механизм (фрагмент):

Код Выделить Развернуть

  ' Отключаем автоопределение высоты строки для диапазона oRange.
    stdHeight=oRange.SpreadSheet.Rows(oRange.SpreadSheet.Rows.Count-1).Height
    oRange.Rows.Height=stdHeight+1 ' устанавливаем нестандартную высоту строки

    ' ---
    ' Здесь все операции по изменению значений ячеек oRange, форматированию...
    ' ---
   
    oRange.Rows.Height=stdHeight   ' восстановили стандартную высоту
   
    oRange.Rows.optimalHeight=True ' форсируем автоподбор высоты

См. также эту тему.

[Massaraksh7]

Попробовал, но вместо 28 секунд стало 43 сек. Хотя, может быть я поставил этот блок в неверном месте.
Процедура обработки у меня такая:
'---Объединение ячеек

Код Выделить Развернуть

Sub setmerge(cov)
r1 = CInt(cov(1))
c1 = CInt(cov(2))
r2 = CInt(cov(3))
c2 = CInt(cov(4))
frng = sheet.getCellRangeByPosition(c1-1,r1-1,c2-1,r2-1)
frng.merge(TRUE)
Answer("OK")
end SubОна в процессе обработки вызывается ~9000 раз.
Я вставил сюда:

Код Выделить Развернуть

'---Объединение ячеек
Sub setmerge(cov)
r1 = CInt(cov(1))
c1 = CInt(cov(2))
r2 = CInt(cov(3))
c2 = CInt(cov(4))
frng = sheet.getCellRangeByPosition(c1-1,r1-1,c2-1,r2-1)
   stdHeight=frng.SpreadSheet.Rows(frng.SpreadSheet.Rows.Count-1).Height
   frng.Rows.Height=stdHeight+1
frng.merge(TRUE)
Answer("OK")
end Sub(Без Answer ничего не меняется.)
Так?

[sokol92]

Вставляем первую часть кода после импорта данных на лист, но перед первой операцией по форматированию ячеек (объединению ячеек).
Первая часть кода выполняется один раз (не 9000), oRange это UsedRange листа.

Вторая часть кода также выполняется один раз после завершения всех операций по форматированию.

[Massaraksh7]

Проверил и по-другому: код вставил в самом начале обработки для однократного выполнения:

Код Выделить Развернуть

arng = sheet.getCellRangeByPosition(0,0,26,9063)
stdHeight=arng.SpreadSheet.Rows(arng.SpreadSheet.Rows.Count-1).Height
arng.Rows.Height=stdHeight+128 секунд.

[sokol92]

Значит, автоподбор высоты строк не при чем (мы его отключили).

Объединенные ячейки все эксперты в Excel и Calc считают "злом". 

[Massaraksh7]

после импорта данных на лист, но перед первой операцией по форматированию ячеек (объединению ячеек).
Первая часть кода выполняется один раз, oRange это UsedRange листа.

Проверил и это:

Код Выделить Развернуть

Sub setmerge(cov)
r1 = CInt(cov(1))
c1 = CInt(cov(2))
r2 = CInt(cov(3))
c2 = CInt(cov(4))
frng = sheet.getCellRangeByPosition(c1-1,r1-1,c2-1,r2-1)

if r1=1 and c1=1 then
   arng = sheet.getCellRangeByPosition(0,0,26,9063)
   stdHeight=arng.SpreadSheet.Rows(arng.SpreadSheet.Rows.Count-1).Height
   arng.Rows.Height=stdHeight+1
end if

frng.merge(TRUE)
Answer("OK")
end SubТе же 28 секунд. Боюсь, что сама операция объединения тормозит, и ничего тут не сделаешь. 

[Massaraksh7]

Объединенные ячейки все эксперты в Excel и Calc считают "злом".

К сожаленю, без "зла" этого трудно получить читаемые отчёты.

[sokol92]

Можно поискать другие возможные причины медленной работы, например, перерисовка экрана и(или) показ границ страниц печати (это и в Excele сильнейшие тормоза).

У Вас после выполнения макроса на листе присутствуют прерывистые линии (границы страниц печати)?

[Massaraksh7]

У Вас после выполнения макроса на листе присутствуют прерывистые линии (границы страниц печати)?

Нет.

перерисовка экрана

В невидимом режиме.

Ладно, ещё поизучаю поведение.