Huge Table Support in Calc

Ahogy azt előjeleztem, készítettem egy buildot, amiben a táblák nagyok, nagyon-nagyok lehetnek, azaz maximum a XFD1048576 cellába lehet adatot rögzíteni. Úgy tűnik, hogy a sorok számának növelésen jelentősen nem veti vissza a teljesítményt, viszont az oszlopok száma bizony nagy teljesítmény eséssel jár. Ez főleg akkor igaz, ha a jobb szélső cellákat szeretnénk használni. Görgetésnél például jól látható a probléma. Nagyságrendileg 1300 oszlop körül helyre áll a rend és teljesítmény megfelelő lesz. Talán ezért lesz a következő OpenOffice.org verzióban, a 3-asban "csak" 1024 oszlop.
Szóval használhatónak használható, de például a keresés dög lassú tekintve, hogy a táblaméret 262144 szeresére nőtt. Nem tudom ez az Excelben hogy került lekezelésre, és kíváncsi lennék milyen sebességgel keres ment egy ilyen szélsőséges helyzetben. A mentés és betöltés egyébként hiba nélkül ment és jelezte XLS fájl mentése esetén, hogy adatvesztés lesz az Excel 2003-as számára nem kezelhető méreteknél. Érdekes SXC esetén ezt nem teszi, mert abba a fájlformátumba jól ment, ellentétben az örökölt bináris SDC formátumba, melynél ugyan nem szólt, de adatvesztés lett.
Ha van kedvetek nyissatok meg ezt pár fájlt a
ftp://ftp.devall.hu/kami/fileformattest/
helyről és írjátok meg a tapasztalataitokat. Kíváncsi vagyok, hogy ez egyes OpenOffice változatok (2.x vagy 3.x béta/fejlesztői) hogyan kezelik a különféle helyen adatokat tartalmazó adatokat.
Azt sejtem, hogy a OOo3-ban bevezetendő változtatások lehet, hogy hibát okoznak a régebbi, 2.x-es sorozattal történő megnyitás esetén. Tehát nem csonkolva nem jelenítik meg, hanem memória szűkössége okán sehogy sem nyitják meg. Legalábbis ezt tapasztaltam...

A tábláktól

  • AMJ65535.ods - 65535x1024 méretű cellában vannak adatok
  • IV65536.ods - 65535x256 méretű cellában vannak adatok
  • IV65536tullogo.ods - 65535x256 méretű cellánál kissé több cellában vannak adatok
  • IV65542.ods - 655425x256, tehát kicsit több sor van benne, mint amennyit a OOo2.x kezelne
  • XFC1048576.ods - Huge Table: XFD1048576

(megjegyzés: csak a megadott mérethez közeli cellák vannak kitöltve...)

Szóval várom a tapasztalatokat...

64 bites Linuxszal rendelkező fórumtársak innen leránthatnak egy tesztelésre szánt verziót (deb és rpm):
http://sourceforge.net/project/showfiles.php?group_id=170021&package_id…

( Elbandi v | 2008. 06. 08., v – 14:06 )

hogy tarolja az ooo a tablakat a memoriaban? letrehoz egy NxM-es matrixot, vagy listaban (X:Y helyen Z van)?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Már csak az a kérdés, hogy ezt még akkor csinálták, amikor zárt forrású volt az elődje, vagy a csúnya, gonosz open source fejlesztők "rontották el". Naponta 100+ zárt forrású programozó munkájára látok rá. Látom a problémáikat, sírásaikat és hogy mikben kell őket szupportálni. Ne akard bemagyarázni, hogy a zárt forrású fejlesztés abból adódóan, hogy zárt forrású, bármben is jobb lenne.

--
trey @ gépház

nem jobb.
de N+1 olyan opensource kezdemenyezet lattam mar, amikor valaki csinalt valamit (programozastechnologiailag is gany modon), aztan verte a mellet hogy az mennyire hiperszuper.

es ne mondd nekem, hogy azt, hogy nem tudja dinamikusan tetszoleges(!) mereture novelni a cellateret jelentos lassulas nelkul, az nem lol...

"de N+1 olyan opensource kezdemenyezet lattam mar, amikor valaki csinalt valamit (programozastechnologiailag is gany modon), aztan verte a mellet hogy az mennyire hiperszuper."

Ugyanilyet láttam / látok zárt forrásúban eleget.

"es ne mondd nekem, hogy azt, hogy nem tudja dinamikusan tetszoleges(!) mereture novelni a cellateret jelentos lassulas nelkul, az nem lol..."

Nem beszéltem semmiféle cellatérről, mindössze arról érdeklődtem, hogy mióta van ez így. Azóta hogy nyílt forrású lett a kód, vagy már előtte is ilyen volt?

--
trey @ gépház

en azert kevesebbet latok az elsobol :) de lehet, hogy Te tobb ilyennel talalkozol, alairom. statisztikailag a mintavetelezesem elhanyagolhato :)

gondolom mar regota igy van amugy, a masodik dolog, de a tisztelt opensource community igazan kijavithatna egy ilyen banalis zartforraskodbol oroklott hibat, hamar ilyen verprofik ;)

Én azon gondolkodtam, hogy hogyan lehet ez a te elméleted szerint.

Van több ismerősőm, aki cégnél megélhetés szinten programoz, de emellett nyílt forrású fejlesztéseket is végez. Előttem van, hogy nappal - amikor a zárt forrású programozó sapka van rajta - akkor kiváló programozó, de ha hazamegy - és a nyílt forrású programozó sapka kerül rá - akkor egyből elfelejti a tudományát. De akkor mi van, ha a munkahelyén a zárt forrású programozó sapkában fusiban nyílt forrású kódot fejleszt? :)

--
trey @ gépház

writeonly vagy?

lent irtam: "nagyresze hobbikoder, en ugy tapasztalom eleg keves resze az, aki (akar autodidakta modon is, de) kepzett programozo (vagy esetleg foallasu, es hobbibol fejleszt valamit)."

nyilvan az aki nappal foallasu koder (esetleg free projekten dolgozik), az altalaban jo kodot ir ejjel is ;)

de szerintem az opensource projektek keves reszen dolgozik nem hobbikoder.

akkor meg szomorubb a helyzet, mint gondoltam...
ha belegondolok hogy szeptembertol kidobhatom a pptxemet, es nekemis ooot kell hasznalni.. gr:)

nade ennyi aldozatot tudok hozni :D

btw, szerinted _normalis_, hogy _belassul_ nem fix tablaternel?

erosen tervezesi hiba imho :)

( Tuschke | 2008. 06. 08., v – 15:50 )

Kipróbálgattam a fájlokat. A fent liinkelt 64 bites verzióval. Megnyitottam, beleírtam, kerestem, stb.
Az xfc1048576 xls és sdc fájlokat rendesen sem megnyitni, sem menteni nem tudja. ods és sxc fájloknál sokáig keres, és nem mindig azt találja, amit kerestem. Pl 7-est keresek, és 3-ast talál.
+ kilépéskor lefagy.
KCrash: Application 'soffice.bin' crashing...
XIO: fatal IO error 9 (Hibás fájl leíró) on X server ":0.0"
after 85 requests (85 known processed) with 0 events remaining.

------------------------
Debian testing KDE amd64
MSI K8N-Neo-4, Athlon64 3800+, Leadtek 6600GT

Mit tapasztalsz, ha nem a fent linkelt verzióval nyitogatod meg?

"nem mindig azt találja, amit kerestem. Pl 7-est keresek, és 3-ast talál."

És ha beikszeled, hogy a "Teljes cellák" lehetőséget?

KAMI
--
Ezt nem nézem meg! | OxygenOffice | OpenOffice.org | Az internet svájci bicskája

"Mit tapasztalsz, ha nem a fent linkelt verzióval nyitogatod meg?"
Majd ha visszatelepítettem, megnézem :)

"És ha beikszeled, hogy a "Teljes cellák" lehetőséget?"
" A keresési kulcs nem található"
Ha nem ikszelem be, akkor talált egy 5-öst a 7-es helyett.
Ellenben az általam beírt 234-et, és 7-es helyére írt 6-ot megtalálta.
.ods fájlon próbáltam.

------------------------
Debian testing KDE amd64
MSI K8N-Neo-4, Athlon64 3800+, Leadtek 6600GT

Ha nem a fenti verzióval nyitom meg, hanem a 2.4.0-12 -vel (080414), akkor elöször is nem tudja megnyitni, majd rögtön eldobja magát.

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

ez a hibaüzenet már a dokumentum helyreállításakor jött. Az XFD-s fájlokat nem is próbáltam, csak az első hármat.

------------------------
Debian testing KDE amd64
MSI K8N-Neo-4, Athlon64 3800+, Leadtek 6600GT

( snq- | 2008. 06. 08., v – 18:05 )

biztos, hogy a próbálgassuk amíg jó nem lesz a legmérnökibb hozzáállás?

( KAMI911 v | 2008. 06. 08., v – 23:28 )

Irodalom a témával kapcsolatban:

http://sc.openoffice.org/row-limit.html
http://qa.openoffice.org/issues/show_bug.cgi?id=30215
http://qa.openoffice.org/issues/show_bug.cgi?id=31612
http://qa.openoffice.org/issues/show_bug.cgi?id=86049
http://sc.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1702

http://blogs.msdn.com/excel/archive/2005/09/23/473185.aspx

KAMI
--
Ezt nem nézem meg! | OxygenOffice | OpenOffice.org | Az internet svájci bicskája