Kohei Yoshida, współautor LibreOffice Calc, zaprezentował na tegorocznym FOSDEM najnowsze informacje o dalszych kierunkach rozwoju tego programu oraz o tym, co praktycznie czeka tylko na najbliższe wydanie.
W tej chwili już z grubsza gotowe jest nowe okienko kopiowania i przenoszenia arkuszy i dwie nowości w pilocie danych: obsługa nieograniczonej ilości komórek oraz możliwość korzystania ze źródła danych w postaci nazwanego zakresu komórek (dzięki temu można go wygodnie modyfikować). Do wersji 3.4 powinno przyspieszyć działanie odwołań zewnętrznych.
Za progiem czekają jednak bardziej zaawansowane zmiany. Na opublikowanych wczoraj slajdach przedstawił trzy znaczne usprawnienia architektury Calca w zakresie modularyzacji i przyspieszenia działania programu: wydzielenie obsługi wielowymiarowych struktur danych, silnika formuł oraz filtrów importu plików.
Wielowymiarowe struktury danych mają być przejęte przez zewnętrzną bibliotekę mdds, która na razie obejmuje do 5 wymiarów i zawiera często spotykane przykłady złożonych danych i algorytmów.
Duży problem stanowi obsługa formuł. Ten podstawowy element arkusza kalkulacyjnego jest obecnie powolny i skomplikowany — obsługuje na przykład 3 składnie zapisu (Calc A1, Excel A1 oraz Excel R1C1) i zbudowany jest z dwóch typów klas. W jego zastępstwie ma się pojawić wielowątkowa biblioteka Ixion. Kod tej biblioteki jest eksperymentalny i nie został jeszcze zintegrowany z LO Calc.
Nie lepiej jest z importem danych z plików, zarówno w formacie ODS (moduły odpowiedzialne to xmloff i sc), jak i XLSX (moduł oox). One także są powolne na zewnątrz i solidnie zabagnione wewnątrz, więc w planach jest wymiana ich na opierająca się o libgsf bibliotekę Orcus. Ona także jest w powijakach, ale już wygląda bardzo obiecująco: test importu dużych ilości niesformatowanego tekstu ODS zszedł z 1:53 minut do zaledwie 12 sekund, a XLSX z 4 minut aż do 5,4 sekundy! Podobno to jeszcze nie koniec zapowiadanego przyspieszenia.
Czy zależności z javy zostały już usunięte?
„no bo przecież JAVA jest wolna” – mit z lat 90.
I dlatego na serwerach mają za dużo wydajności i używają właśnie JAVĘ. Google też celowo strzelił sobie w stopę korzystając z Dalvika na Androidzie 😉
.
Jest tak szybka, że jak mam dokument w Calcu składający się z 20 arkuszy a każdy po 300 kolumn i 5000 wierszy to zrobić z nim cokolwiek (wykres, tabelę przestawną, …) to można się wyspać. Dla porównania inny arkusz kalkulacyjny z nazwą na „e” robi to samo z tym samym dokumentem w kilka sekund.
Pytanie tylko czy to jest wina Javy? A może to kod C++ jest taki wolny?
Tak, c++ jest znany z powolności…
@Mieszko Kaczmarczyk – to sprawdź czy masz proces javy odpalony w sytuacji o której piszesz. Ja w Calcu, żadnego procesu JAVY odpalonego nie mam.
dla wprawnego oka podpowiedź – prędkość zależy bardzo często od kwestii jak w językach obiektowych podchodzi się do kwestii klas i obiektów. Bardzo często programiści zwłaszcza zaraz po studiach mają skłonności do nadtworzenia ilości klas i obiektów. Tym samym, jeśli do tego dorzucimy zfragmentowanie pamięci, to uzyskujemy spowolnienie działania programu bez względu na to, czy to jest JAVA czy C++.
Swoją drogą w sytuacji np. zfragmentowania pamięci, to JAVA poradzi sobie swoimi mechanizmami lepiej, bo potrafi dynamicznie przealokować obiekty w wolnym czasie procesora.
@pogromca [9:51]:
Ja nie odpalam LO w przeglądarce więc procesu Javy nie ma i nie będzie – LO jest skompilowane do binarki – LO nie działa jako aplet.
@pogromca [9:56]:
Nie bardzo rozumiem jak sobie Java ma poradzić lepiej niż C++, skoro maszyna wirtualna Javy jest napisana w C++ a nie np. w Asemblerze.
Nie, nie o to chodzi. Chodzi o politykę nowego właściciela. Nie napisałem, że java jest wolna.
mi też się ta polityka średnio podoba. Mam nadzieję, że po pewnym czasie zmiękną. Może starcie z Googlem trochę ich utemperuje ?