Megjelent a LibreOffice 25.2.7

LibreOffice, OpenOffice.org

Megjelent a LibreOffice 25.2.7-es kiadása. Ez az utolsó kiadás a 25.2-es ágban, ezért minden felhasználónak javasolt mielőbb az újabb stabil ágra váltania:

Post by @libreoffice@fosstodon.org
View on Mastodon

Bejelentés itt.

( yoursoft | 2025. 10. 31., p – 12:45 )

10-500 ezer soros Calc fájokat használok. Bennük sokszor pl. "összefűz" képletekkel. Ebben nagyon lassú tud időnként lenni a Libre.

MS Office-ben nem voltak ilyen gondjaim.

Hagyjuk már, pár százezer sor az lófasz kb bármilyen scriptnyelvnek, ha mégse, akkor bele lehet hányni egy sqliteba, vagy belehányni valami basbe, ilyesmibe. (Dzerintem az excelnek is lófasz, én már tizensok éve is csináltam vele ilyeneket, emlékszem még, mikor végre lehetett több mint 64k sort beleverni, semmi oka nincs valójában, hogy a calcban lassú legyen). Dolgozzon fel textet C-ben az, akinek két anyja volt, orbitális szopás, egy rakás hülyeséggel kell szenvedni, ami máshol just works. És ide a rozsdás bökőt, hogy ha tényleg speed kritikus, akkor leakasztva valamit, amiben erre megfelelően kioptimizált eszközök vannak, akkor mondjuk egy java gyorsabb lesz, mint amit te gyorsan összekézműveskedsz C-ben :)

Teljesen jogos. Java-ban szoktam elődolgozni.

Az adatok egyébként DB-ben vannak. Onnan szedem ki (vagy az a cél ahova betöltöm), majd régebben Excelben, most meg Calcban kényelmesebb rendezni / szűrni / szerkeszteni / hasonlítani másik időszakos táblázatokkal.

Majd SQL-t állítok össze az oszlopok alapján és úgy töltöm vissza DB-be.

Amit egyszerűbb azt közvetlenül DB-ben szerkesztem DBeaver-el.
A DBeaver egyébként mostanában nagyon be tud lassulni ha több ezer sort szerkesztettem / mentettem. Valószínűleg memória luk. De ez egy másik történet.

Miért szemellenző? Assembly kód lenne a leggyorsabb, de assembly-ben tényleg fájdalmas megcsinálni dolgokat, a C viszont elég közel van hozzá, s könnyebben emészthető. Abban igazad van, hogy ha használsz megfelelően optimalizált library-ket a kritikus részekhez, amelyeket assembly-ben vagy C-ben írtak, akkor szinte mindegy, milyen nyelven írod.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért, mert láthatólag fogalmad sincs sem arról, hogy valójában mennyi "felesleges" pepecselés kb bármi magasabb szintű nyelvhez képest ilyet C-ben csinálni, sem arról, hogy ezek a nyelvek jellemzően mekkora sebességre képesek, sem arról, hogy az ilyen alapvetések mennyi mindent jobban csinálnak kb lendületből mindenféle spec library nélkül (mert azt hiszed, hogy az a normális, hogy pl a normálisan megcsinált string kezelés már spec library, nem alap dolog), sem arról, hogy a konkrét probléma mennyire nem nagy valójában, ezért mennyire érdektelen az, ha a végeredmény akár jó párszor gyorsabb, ha összeveted a pepecselés idejével.

Csak tolod, hogy mer a C a gyors.

Ezzel lényegében azt mondtad, hogy nem is kell annyira gyorsnak lennie, mint amennyire tudna, amiben egyébként igazad van.

Jó, akkor legyen például awk, mert az sokkal lassabb lesz, mintha C-ben lenne megírva, de vélhetően még mindig sokkal gyorsabb, mint az LO Calc.

Amúgy a mondandóm lényege az volt, hogy az LO Calc szerintem nem erre való, nem azzal kell megoldani mindent.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezzel lényegében azt mondtad, hogy nem is kell annyira gyorsnak lennie, mint amennyire tudna

Hát, mondjuk. Valójában azt mondtam, hogy ennek kb bármiben bőven elég gyorsnak kellene lennie, cserébe C-ben csinálni kb bármi másnál sokkal szarabb. (Mármint, jó "ha valamiáltalánosat akarsz, az több év meló" LOL)

Jó, akkor legyen például awk, mert az sokkal lassabb lesz, mintha C-ben lenne megírva,

Hát, most vagy arra kell felhívnom a figyelmed,

  • hogy az awk egy C program, miért lenne lassabb sokkal
  • vagy arra, hogyha sokkal lassabb egy olyan feladatban, ami kifejezett célja, akkor miért írtak ilyen szar C programot
  • vagy arra, hogy az awk egy line feldolgozó scriptnyelv, ha az jó, miért ne lenne jó bármelyik másik is?

de vélhetően még mindig sokkal gyorsabb, mint az LO Calc

Ez a vélelem valójában egyáltalán nem kellene, hogy megalapozott legyen. Miért kéne feltételezünk, hogy az L0 lassabban tud végigszámolni egy datasetet, mint az awk. Kb ugyanazt csinálják minketten. Nem sok architekturális különbség van egy line olvasó, szeletelő, majd azon fucntionokat meghívó, és egy mátrixot tartó,  functionokat meghívó cucc között, kb ugyanazt kell csinálni.

Amúgy a mondandóm lényege az volt, hogy az LO Calc szerintem nem erre való, nem azzal kell megoldani mindent.

Egyrészt akkor elég jó eltitkoltad a mondandód lényegét :)

Másrészt a Calc meg az excel egy elég jó tool arra, hogy gyorsan lehessen vele programozáshoz kevésbé konyító embereknek ilyesmit csinálni (és nem mellesleg sokkal könnyebb utána azokkal az adatokkal kezdeni valami elemzést)

Harmadrészt "a  C szerintem nem erre való, nem azzal kell megoldani mindent." ;)

Így már részben egyetértek veled. Az, hogy az awk egy C program - gondolom, úgy érted, hogy C-ben írták -, most nem túl releváns. Egy bytecode-ra fordító script nyelv. Tehát interpreter. Ha így nézzük, akkor minden assembly, helyesebben minden gépi kód, hiszen a CPU futtatja, ha nem közvetlenül, akkor az interpretert. Innen nézve az LO Calc egy gépi kód. A sebesség attól függ, hogy lusta a programozó, és egymás hegyére-hátára pakol rengeteg réteget, az interpreter interpreterének interpretere esetleg meg lett írva C-ben, egy compilált nyelven, meg amit sokszor kell kiszámolni, azt sokszor számolják ki, vagy útközben letárolják egy struktúrában a részeredményt. A programozók többsége lusta, ami miatt a CPU-k nagyjából CALL és RET utasítások tömkelegét, meg memória másolgatásokat hajtanak végre, hogy a rengeteg egymásba ágyazott függvény végén megcsillanjon az az utasítás, ami érdemben csinál is valamit.

Alacsonyabb szinten programozva ezt a rengeteg bloat feleslegességet el lehet takarítani, cserében speciálisabb, nem elég általános lesz a kód.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

van. de ezt eleg lenne pythonban, ott azert egyszerubb es eleg sok lib is van ami ezt tamogatja (cvs kezelestol a numpy-ig), pypy-vel (JIT) pedig c-hez kozeli sebesseggel fog futni, vagy akar meg annal is gyorsabban, gpu/cuda eseten (ha a tomeges szamolast pl numpy-vel vegezteted).

500 ezer soros Calc fájokat használok

LO ökoszisztémában maradva, mi szólt a Base ellen hogy nem azt választottad egy ilyen nagy adathalmaz tárolásához, amiből kiszolgálhatók a Calc-os feldolgozások (datasource vagy link)? 

Vagy a félmillió sor már az aggregált / összegzett feldolgozott adat?