01:02 <lo-ru-tg> Андрей (@a​ndrew_fv) has joined the Telegram Group!

01:04 <lo-ru-tg> <a​ndrew_fv> всем привет. Можно ли как-нибудь ускорить операцию сохранения документа? После нажатия CTRL-S интерфейс блокируется почти на секунду.

04:44 <lo-ru-tg> <a​ndrew_fv> [EDIT] всем привет. Можно ли как-нибудь ускорить операцию сохранения документа? После нажатия CTRL-S интерфейс блокируется почти на секунду. Kubuntu 20.04

08:27 <lo-ru-tg> <economist> 15 шт АРМ на Ubuntu 20.10 и включено автосохранение у всех. Жалоб нет.

09:21 <lo-ru-tg> <K​ompilainenn> Нет, и целая секунда это мизер

09:21 <lo-ru-tg> <K​ompilainenn> Хотя хотелка про асинхронное сохранение была

10:53 <lo-ru-tg> <PS> У меня файл таблица 60мБ 150 тыс.строк сохраняется по минуте на Corei5/8Gb/SSD

10:53 <lo-ru-tg> <PS> При этом все 4 ядра забиты на 100%, а память на глазах выедается. Несколько раз перед сохранением около половины было свободно, в процессе сохранения выедается, и вылетает (перезапускается офис).

10:53 <lo-ru-tg> <PS> И ещё - после закрытия документа память не освобождается - приходится все документы закрывать и офис целиком - тогда освобождается.

10:57 <lo-ru-tg> <K​ompilainenn> а это беда у Либры да. Проблема выжирания памяти при сохранении огромных документов имеет место быть

11:25 <lo-ru-tg> <K​ompilainenn> надо профилировать и дебажить, а кодерам некогда

12:45 <lo-ru-tg> <T​anaTiX> Может вместо таких файлов целесообразно юзать БД?

12:48 <lo-ru-tg> <K​ompilainenn> разработчики либры запилили расширение электронных таблиц до миллиона столбцов и 16 миллионов строк

12:48 <lo-ru-tg> <K​ompilainenn> видимо они считают, что такие объемы таки востребованы в таблицах

15:50 <lo-ru-tg> RASMUSSEN (@t​eqokixavene6573) has joined the Telegram Group!

15:51 <lo-ru-tg> 'Untitled Image' uploaded by t​eqokixavene6573: https://i.imgur.com/voZGkLJ.jpg

16:05 <lo-ru-tg> <T​anaTiX> Мону Лизу и в пэинте нарисовать можно, но есть более подходящие инструменты.

16:06 <lo-ru-tg> <K​ustovV> Для рисования Моны Лизы в пейнте лучше всего подходит именно пейнт

16:06 <lo-ru-tg> <T​anaTiX> Не мне учить, но...

16:06 <lo-ru-tg> <T​anaTiX> Если начинаются проблемы с производительностью (в т.ч. на уровне использования), то стоит обдумывать оптимизацию.

16:07 <lo-ru-tg> <K​ustovV> А тут уже не поспоришь 😊 +1 довод к прямым высказываниям 😊

16:07 <lo-ru-tg> <T​anaTiX> Если орудия труда ограничены только пэинтом, то мне парировать нечем 🤷‍♂

16:08 <lo-ru-tg> <K​ompilainenn> тут думать нечего, надо только найти хотя бы одного кодера, скиллового в С++, который бы уделил внимание именно оптимизации, хотя бы в Кальк

16:08 <lo-ru-tg> <K​ustovV> Нет, я про то, что иногда способ достижения является (само)целью. В искусстве такое чаще чем в IT, посему пример ИМХО не очень удачный 😊

16:09 <lo-ru-tg> <T​anaTiX> Это уже на усмотрение владельца проблемы

16:10 <lo-ru-tg> <K​ompilainenn> https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=REOPENED&component=Calc&f1=keywords&list_id=1242657&o1=equals&product=LibreOffice&query_format=advanced&resolution=---&v1=perf

16:10 <lo-ru-tg> <K​ompilainenn> всего 100 багов про оптимизацию в Кальк

16:24 <lo-ru-tg> <economist> У Excel ровно такие же проблемы с гигатаблицами, долгим сохранением, вылетами с потерей несохр изменений, и бедненькое подобие БД. Я бы на месте разработчиков Calc - праздновал нг, а не баги тащил. Пусть сначала Excel все исправит.

16:27 <JohnDoe_71Rus> ну так пользователи просят "хотим как в Excel"

16:27 <JohnDoe_71Rus> приходится баги воспроизводить

17:38 <lo-ru-tg> <G​lebzilla_M> я делал ВПР на ~50 000 строк, либра смогла, эксель, возможно, тоже, но я этого не увидел

17:39 <lo-ru-tg> ARNAUD has joined the Telegram Group!

17:39 <lo-ru-tg> 'Untitled Image' uploaded by ARNAUD: https://i.imgur.com/RFbuXv6.jpg