LINUX.ORG.RU

Что использовать вместо Libreoffice Calc для удобного и быстрого расчета

 ,


0

3

Сейчас использую calc, но работает это все хуже. Смысл: есть документ состоящий из 2 листов. На 1 листе (лист данных) ежедневно заношу данные в 10 колонок. На 2 листе (лист анализа) некоторые расчеты (средние, максимумы/минимумы, медианы и прочее). Периодически требуется что-то дополнительно посчитать, что требует написания формул на 2 листе, отличных от тех, что там обычно. Чем дальше, тем больше во всем этом тормозов. Сейчас данными заполнено всего около 7 тыс. ячеек, расчетами около 50. Чтобы мне заполнить ячейку и увидеть результат перерасчетов требуется секунд 5. Причем почти не важно, на каком железе это делаю (самое производительное - ryzen 5900x с nvme и 64 Гб ОЗУ). Работать некомфортно, а данные надо заполнять дальше. Разбивать их на разные документы неудобно, потому что постоянно требуется сравнение из анализа на 2 листе, в котором должны быть все данные сразу, а периодические расчеты требуют выделения областей (слайсов) и их анализ + графики.

Вопрос: чем заменить calc при таком сценарии использования и сохранении максимального удобства использования или как разогнать calc до нормальной производительности? Я смотрел в сторону заполнения базы данных, вроде sqlite, и обработки данных на python через pandas, но это требует постоянной возни с кодом из-за потребности периодически досчитывать что-то дополнительно и строить графики. Какие есть еще варианты?

Дополнение. Данные нужно периодически предоставлять для ознакомления другим людям, поэтому должна быть выгрузка в человекочитаемые форматы. Лучше pdf. Если идти через python+sqlite это еще одна проблема.



Последнее исправление: GrayFox (всего исправлений: 1)

Ответ на: комментарий от Shprot

Там еще хуже. Этот чудо-офис падает без остановки, не говоря о том, что разработка сомнительная сама по себе.

Отбивая похожие вопросы: WPS office, OOO и прочие аналоги-заменители опробованы. Там ничего, решающего мою проблему нет. Чаще только хуже.

GrayFox
() автор топика

7 тыс. ячеек и 50 формул - это очень много. Современным компьютерам всего с 64Gb памяти быстро с таким не справиться. Нужен или кластер, или GPU :)

Но как альтернативу предложу Microsoft Excel. Еще данные можно хранить в обычном текстовом файле.

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

Прошу прощения, не понял, это сарказм или нет?

7 тыс. ячеек и 50 формул - это очень много. Современным компьютерам всего с 64Gb памяти быстро с таким не справиться. Нужен или кластер, или GPU :)

Но как альтернативу предложу Microsoft Excel.

Я знаю, что Excel такое переваривает лучше, но я предпочту не пользоваться MS Office без крайней нужды, пока есть какие-то другие варианты.

Еще данные можно хранить в обычном текстовом файле.

Имеется ввиду статистические данные? Я пробовал статистику писать в csv, а в другом документе делать анализ, но тормоза никуда от этого не пропали.

GrayFox
() автор топика

В своё время была похожая проблема, я пользовался ГуглТаблицами. Решение лежит в разделение форм ввода от отчётности. В итоге получилась такая распределённая БД. Когда с нескольких файлов сливаются данные в одну большую таблицу, и по ней уже идёт расчёт показателей.

А вообще конечно это перенос данных в бд. А для отчётности использовать datastudio или что то подобное.

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

Читаю сейчас про хранение данных в бд и везде пишут, что бд из одной таблицы это не комильфо.

Data studio имеется ввиду гугловская? По запросу сначала выдает какую-то Looker studio. Если оно, какие у них есть альтернативы для работы локально или хотя бы self-hosted? Учитывая ситуацию в РФ, с опаской отношусь к завязке на зарубежные сервисы.

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

Ну не комильфо, то оно не комильфо, но всё таки давайте от задачи отталкиваться. У Вас сейчас одна таблица, и проблема с производительностью, её и решаем. А она именно в том что по большому массиву данных в он-лайне идёт пересчёт, более одного показателя.

Looker studio да теперь оно так называется. Она умеет в множество источников в том числе и в локальный постгрес и mysql. Но там и облачных много.

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

Конечно же это сарказм. Например чтобы вывести jpeg-картинку на монитор, хоть пусть даже размером 800х600, или допустим её преобразовать, нужно перелопатить 800х600=480 000 (четыреста восемьдесят тысяч, Карл) пикселей. На этом фоне 7 тысяч вообще ни о чем и 5 секунд уходят явно не на расчет.

В текстовом файле можно хранит хоть статистические данные, хоть географические, хоть физические. Какие угодно. Файл нужно этим вашим python-ом (или кто чем умеет) считывать, применять формулы и выводить картинки. Мой посыл был в том, что на таких объемах/задачах база данных нафиг не уперлась.

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

Я подозреваю, что проблема не в заполнении большого объема, а именно в формулах. То есть кальк тормозит на расчетах при запуске и перерасчетах при изменении данных. Поэтому изменение формата хранение статистики не приведет к увеличению производительности в данном конкретном случае. Хоть в csv их буду хранить, хоть в чем-то другом. Потому в голову и пришло, что дело в обработке данных при расчетах, поэтому нужно выбирать другой инструмент для анализа (например, python), а не заполнения данных. Но тут уже свои вопросы встают: как удобно перерасчитывать, когда нужно посчитать что-то отдельно от уже написанных формул, как строить графики, как выводить все это в человекочитаемый формат, а не только в терминал.

GrayFox
() автор топика

Чудес не бывает (на компах).

Ускорить расчеты можно используя языки программирования вместо calc, но там будет полная катастрофа с визуальной интерактивной составляющей этого процесса работы.

James_Holden ★★★
()

Вариант оптимизировать расчёты не рассматривается?

Потому что 7 тыс. строк - это не сильно много (у меня и побольше есть), но некоторые функции (типа подмножества LOOKUP) сами по себе достаточно тяжёлые и на большом объёме данных начинают тормозить. Также оптимизировать можно и размещение данных (диапазоны разнести, например, чтобы тех-же поисков было меньше).

И, кстати, версия LO? Если я ничего не путаю, толи в 6-ветке, толи в 7-ветке были значительные ускорения в функциях Calc.

SkyMaverick ★★★★★
()

Я смотрел в сторону заполнения базы данных, вроде sqlite

This. Если объём данных будет расти и дальше, можно даже что-нть помощнее из СУБД взять. Да, потребуется покодить, зато тут ты полный хозяин данных и можешь с ними делать всё. Я бы, по крайней мере, пошёл по этому пути.

P.S. Присоединяюсь к пожелавшим узнать версию Либреофиса.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)

как разогнать calc до нормальной производительности?

Можете попробовать спросить на ask.libreoffice.org, но там, как и при любой дистанционной помощи, помочь не смогут, если подробно не опишите версии ПО и не приложите сам файл, который вызывает проблемы, чтобы они смогли воссоздать ваш кейс у себя.

mydibyje ★★★
()

Версии от 6.2 прошел все (буквально). Сейчас в системе 7.5.3 и appimage с 7.4.7. Все свежее. Сам надеялся, что с обновлениями станет лучше. Чудо так и не случилось.

GrayFox
() автор топика
Ответ на: комментарий от SkyMaverick

LOOKUP есть, да. Разносить по диапазонам не получится, потому что критерии поиска меняются, а значит надо будет почти каждый день перестраивать диапазоны, чтобы LOOKUP не использовать. Это еще больше ручной работы.

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

Тогда рекомендую Spyder ide - там можно сразу табличку посмотреть, и как блокнот без блокнота можно работать - лично меня Jupyter блокноты бесят

Shadow ★★★★★
()

Ерунда какая-то, не может оно тормозить так сильно на такой мелочи. У меня были таблицы с десятками тысяч vlookup на сотнях тысяч строк данных, было приемлемо.

Как временное решение могу предложить отключить автоматический расчет и тыцкать кнопку вручную.

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

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

по сути тебе нужен простейший ввод чем угодно в CSV файл в текстовом формате, а потом преобразование в CSV же. с этим справятся куча простых и быстрых программ. например, awk:

sort -n file | awk ’ { a[i++]=$1; }
END { x=int((i+1)/2); if (x < (i+1)/2) print (a[x-1]+a[x])/2; else print a[x-1]; }’

#/usr/bin/env awk
{count[NR] = $1;} END {
if (NR % 2) {
print count[(NR + 1) / 2];
} else {
print (count[(NR / 2)] + count[(NR / 2) + 1]) / 2.0;
}
}

mumpster ★★★★★
()

Как уже писали выше, посоветовал бы или python + pandas (опционально Jupiter), или R + RStudio.

Да, придётся покодить, но будет гораздо быстрее, больше возможностей и код в гит для документации.

А потом можно и интеграции, и визуализации, и чёртзнаетчтоещё :)

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

Так где у тебя тормоза? Заполнение данных или обсчет? Если последнее, то R херачет все в память и обращение к данным идёт молниеносно. Когда был слив Яндекса, я интереса ради залил csv в 10млн строк в R, сколько хватило памяти и считал медианы и строил графики за единицы секунд.

einhander ★★★★★
()
Последнее исправление: einhander (всего исправлений: 1)

Два листа, семь тысяч ячеек и тормоза в расчетах. Что-то странное. У меня был файл ~60.000 формул, тоже руками заполнялся только первый лист, остальные листы заполнялись автоматом. Все стреляло как из ружья.

foxy_ant ★★
()