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

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?