Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Optymalizacja w LibreOffice 4.2

Druga beta najnowszego LibreOffice'a jest już daleko za nami, a nieliczne portale - jeśli w ogóle poruszyły ten temat - potraktowały go pobieżnie, spłaszczając jego treść do prostych sloganów typu "ulepszono" i "poprawiono". Aż żal było to czytać, dlatego też prezentuję parę ciekawych informacji o efektach kilku optymalizujących kod zabiegach, jakich dokonano w wersji 4.2.

Szybszy eksport komórek bogatych w treść

To, co dotychczas przyciągało uwagę to powolne tempo podczas zapisu dokumentów w natywnym formacie ODS. Było to szczególnie zauważalne wówczas wtedy, gdy arkusz zawierał wiele komórek bogatych w treść.

Komórki bogate w treść są po prostu komórkami zawierającymi różnorodne formatowanie lub tekst składający się z wielu linii. Komórki te obsługiwane są w inny sposób od prostych, wewnętrznych ciągów i wymagają nieco więcej nakładu pracy niż ich proste odpowiedniki. Z tego też powodu zapisywanie dokumentów bogatych w tekst zawsze trwało dłużej niż zapisywanie dokumentów z tylko liczbami i prostymi ciągami.

Jakkolwiek by się nie tłumaczyć, ogólny kierunek rozwoju poszedł w złą stronę i nareszcie postanowiono zrobić z tym porządek. Zoptymalizowano algorytm oraz wyeliminowano zbędne procesy alokacji i dealokacji pamięci. Dzięki temu Calc 4.2 okazał się być najszybszym arkuszem w historii LibreOffice.

Pomiar wykonano na nowym pliku, gdzie w komórce A1 umieszczono trzy razy słowo "libreoffice" (każe w osobnym wierszu), a następnie zreplikowano komórkę do obszaru A1:N1000 i wykonano pomiar prędkości zapisu.

Redukcja zużycia pamięci podczas używania współdzielonych formuł

Jak twierdzi główny deweloper Calca, arkusz kalkulacyjny doczekał się w końcu "implementacji frameworka współdzielenia formuł z prawdziwego zdarzenia". Nowy Calc współdzieli instancje tablic znaczników pomiędzy sąsiadującymi ze sobą komórkami (formułami) jeśli tylko zawierają one identyczny zestaw znaczników formuł.

Ponieważ główną zaletą współdzielonych formuł jest zredukowanie zajętej pamięci, postanowiono zmierzyć trend jej użycia od wersji 4.0 do aktualnej wtedy kompilacji z głównej gałęzi rozwojowej.

Pomiaru dokonano na dokumencie (5.2 MB), który zawierał w sobie 100 tysięcy wierszy w czterech kolumnach, z czego 399 999 z nich zawierało w sobie formułę.

Kolumna A zawiera serię liczb całkowitych, których wartość wzrasta liniowo wraz z każdym wierszem. Tylko pierwsza komórka (A1) jest liczbą, podczas gdy reszta jest formułami. Każda następna komórka odnosi się do poprzedniej (A5 odwołuje się do A4, A4 odwołuje się do A3 itd). Wszystkie komórki w kolumnie B odwołują się do kolumny A, natomiast wszystkie komórki w kolumnie C odnoszą się do kolumny B i tak dalej. Odwołania użyte w dokumencie mają charakter odwołań względnych; żadne relacje bezwzględne nie zostały użyte.

Pomiaru dokonano na systemie openSUSE 11.4 (x64), gdzie tylko wersja 4.0.1 pochodziła z linuksowego repozytorium. Kolejne kompilacje pochodzą z oficjalnych gałęzi projektu, a sam pakiet został zbudowany na lokalnej maszynie programisty.

W przypadku każdego testu pomiar zużycia pamięci był mierzony przez bezpośrednie otwarcie testowego dokumentu z linii poleceń i odczytanie wirtualnej pamięci przez Monitor Systemu w środowisku GNOME. Po wczytaniu dokumentu odczekano kilka sekund, aby ustabilizować zużycie pamięci. Efekty przedstawia poniższy wykres:

Dodatkowo pomiar liczb instancji tablic znaczników pomiędzy dwiema kompilacjami (jednej z opcją współdzielenia formuł i drugiej bez niej) pokazał, że kompilacja bez współdzielenia formuł utworzyła 399 999 instancji tablic znaczników (dokładnie 4 x 100 000 - 1) w czasie wczytania pliku, podczas gdy kompilacja ze współdzielonymi formułami utworzyła jedynie 4 instancje tablic znaczników.

To prawdopodobnie wyjaśnia różnicę 78.3 MiB wirtualnej pamięci pomiędzy dwiema kompilacjami.

Szybsze wyszukiwanie w pionie

Lionel Dricot, jeden z pracowników firmy Lanedo, opisał przypadek współpracy swojej firmy z holenderską spółką Moonen Packaging. Firma zgłosiła błąd, w którym skarżyła się na powolne działanie funkcji WYSZUKAJ.PIONOWO (VLOOPUP) w przypadku odnoszenia się do zewnętrznych arkuszy z dużą ilością wierszy.

Lenado zidentyfikowało dwie sytuację i 2 przypadki dla każdej z nich. W pierwszej sytuacji (A) otwarto dokument i wykonano polecenie WYSZUKAJ.PIONOWO. W drugiej sytuacji (B) otwarto dokument zawierający dane źródłowe przed wykonaniem formuły. W obu przypadkach wykonano prostą formułę (na komórce A1 i B1) lub całkowicie wypełniono arkusz, aby móc wykonać więcej niż 10 tysięcy operacji WYSZUKAJ.PIONOWO (A2 i B2). Ze względu na szczególne mechanizmy pamięci podręcznej, nie ma gwarancji, że jedna operacja WYSZUKAJ.PIONOWO będzie szybsza niż 10 000 podobnych żądań.

Wyniki były gorsze niż złe. Komórka A1 zajęła 153 sekund, A2 zajęła 87 sekund, B1 zajęło 133 sekund, a B2 zajęło to... cały, jeden tydzień!

Sytuację udało się doprowadzić do (niemalże) akceptowalnego stanu rzeczy. Holendrzy przygotowali bardzo dobrze opracowany raport błędu, który - jak twierdzi pracownik Lanedo - pozwolił zaoszczędzić firmie sporą sumę pieniędzy.

Już po naprawie, czas reakcji w tych samych dokumentach zmniejszył się do sporo niższych wartości. A1 zajmuje 40 sekund, A2 zajmuje tylko 9 sekund, B1 zajmuje 35 sekund, a czas oczekiwania w B2 zredukowano z tygodnia do dwóch dni. Wciąż jest to spory interwał, a według eksperymentów, czas ten można zredukować z 48 godzin do... 10 sekund lub nawet mniej! Niestety badania tego typu wymagają kilka dni ciągłej pracy po stronie Lanedo, co jest niestety poza budżetem projektu.

Gdyby jednak jakiejś firmie zależało na (płatnym) udoskonaleniu działania funkcji WYSZUKAJ.PIONOWO, Lanedo chętnie podejmie się zlecenia.

Nowy, szybki silnik bazy danych

Komponent Base 4.2 jest pierwszym, który zawiera w sobie eksperymentalną obsługę relacyjnej bazy danych Firebird. Dotychczas LibreOffice, jak i OpenOffice bazowały na silniku HSQLDB 1.8, jednakże z planów na przyszłość obu projektów wynikają odrębne cele.

Apache OpenOffice będzie migrował na HSQLDB 2.2.x, podczas gdy deweloperzy LibreOffice będą stopniowo wycofywać się z silnika tego rodzaju. Proces ten ma potrwać przez następnych kilka wydań i zakończyć się czymś, co pozwoli dokonać łatwej migracji ze starego typu silnika na nowy. Połączenie się z nowszą wersją HSQLDB 2.x wciąż będzie możliwe dzięki natywnemu interfejsowi zwanemu JDBC.

Jedną, natychmiastowo zauważalną różnicą jest pozbycie się ogromnej pauzy, która powstawała podczas wczytywania bazy, a którego powodem był start wirtualnej maszyny Javy (JVM).

Chociaż głównego przyśpieszenie czasu reakcji oczekuje się podczas pracy z właściwymi danymi, wykonano test polegający na wstawianiu i odzyskiwaniu 120 tysięcy ciągów (był to zrzut danych ze słownika aspell), którego poniższe rezultaty przedstawiają znaczącą przewagę bazy Firebird nad jego poprzednikiem.

Projekt nie został całkowicie ukończony i niektóre kreatory Base wciąż wymagają Javy, co może wywoływać pauzy w różnych punktach czasu. Przepisanie całości do C++/Pythona jest zaplanowane na następne wydania.

Aby móc pracować z nową bazą danych, trzeba aktywować eksperymentalne funkcje w menu Narzędzia > Opcje > LibreOffice > Zaawansowane. Nowe wydanie jest efektem prac Andrzej Hunta, studenta-weterana, który nowy silnik zaimplementował w ramach programu Google Summer of Code.

Poprawa wydajności obliczeń dzięki OpenCL

Na początku lipca firma AMD przystąpiła do Rady Doradców fundacji z zamiarem przyśpieszenia działania Calca w oparciu o GPU, a już dzisiaj możemy smakować owoców tej współpracy.

Zaproponowane przez AMD rozwiązanie wykorzystuje architekturę HSA (Heterogeneous System Architecture), w której procesor graficzny ma dostęp do tej samej pamięci co aplikacja, i która szczególnie efektywna jest w czipach APU, gdzie zarówno GPU, jak i CPU znajdują się w tym samym układzie. Nie trzeba tu więc wydzielać specjalnych zadań dla procesora graficznego i koordynować jego współpracę z głównym procesorem przez wąskie gardła kontrolerów pamięci. Sprzętowa akceleracja dla arkusza kalkulacyjnego ma polegać na wykryciu możliwych do optymalizacji formuł w komórkach, przekształceniu ich na kod OpenCL, skompilowaniu kodu OpenCL na procesor graficzny, a następnie uruchomieniu formuły na GPU. Ma to być, według Micheala Meeksa, szczególnie efektywne dla dużych arkuszy, zawierających liczne powtórzenia tych samych formuł. Zmiana ta ma szansę na szybką popularyzację, zwłaszcza od wydania LibreOffice 4.2, który to umożliwia tworzenie dokumentów o rozmiarze nawet do czterech gigabajtów.

Na pytanie czy systemy z GPU Intela i Nvidii również będą beneficjentami zmiany, Meeks odpowiedział: "jeśli dostawca posiada dobrą implementację OpenCL, będziemy ją wykorzystywać i to powinno być ok".

Ogólna poprawa jakości kodu dzięki analizie Coverity

Coverity jest dostawcą narzędzi do testowania jakości oprogramowania w tym narzędzi do odnajdowania luk bezpieczeństwa w kodzie źródłowym, defektów i błędów poprzez analizę statyczną. Od 2006 roku współpracuje z Departamentem Bezpieczeństwa Krajowego Stanów Zjednoczonych, skanując kod źródłowy różnorakiego oprogramowania Open Source.

Coverity swego czasu współpracowało z projektem OpenOffice.org, a w listopadzie opublikowało raport z analizy kodu LibreOffice 4.1 (dostępny po rejestracji).

Efektem skanu było wyłapanie różnorakich błędów w tym m.in. błędnego użycia API, niespójności hierarchii klas, niewłaściwych wyrażeń czy wycieków pamięci (pełna lista na stronie czwartej raportu). Skutkiem współpracy firmy Coverity z The Document Foundation jest rozwiązanie prawdopodobnie rekordowej liczby błędów w jednej becie (1131 poprawek!). Również analiza kodu LibreOffice 4.2 potwierdziła spadek liczby błędów i poprawę jakości kodu.

I to by było na tyle w dzisiejszym odcinku. Dziękuję za uwagę i do zobaczenia. ;-) 

oprogramowanie

Komentarze

0 nowych
wojtekadams   18 #1 11.12.2013 12:18

Czyli teraz będzie szybszy od MS Office? - takie biurowe Ferrari :)

Quest-88   15 #2 11.12.2013 13:10

Na pewno będzie dobrą wymówką do zakupów. ;-)

"A faster LibreOffice, Meeks joked, will help users "find a business reason to buy the very fastest 3D graphics card you can for your computer. I think that's an important value add to many business users of technology. When your boss comes and says, 'Why have you got this graphics card that's the size of a fridge?' you can say, 'My spreadsheet has got to get faster.'"

2099   8 #3 11.12.2013 14:04

Potestujemy i poczekamy na produkcyjne wydanie. Na razie u mnie w firmie poszedł w odstawkę na rzecz AOO.

Druedain   13 #4 11.12.2013 15:25

Świetne podsumowanie, aż miło poczytać :)

Songokuu   14 #5 11.12.2013 16:14

@Quest-88

Muszę powiedzieć w pracy, że musimy kupić Radeona 290X, żeby BattleOffice nam nie przycinał :P

A tak w ogóle to dzięki za te wpisy.

Songokuu   14 #6 11.12.2013 16:15

...a może to LibreField przycinał?...

artymienek   6 #7 11.12.2013 17:39

Bardzo fajny opis i takich mi często brakuje do programów typu właśnie pakiet biurowy. Swego czasu podobny pozwolił mi napisać do końca pracę magisterską, bo dowiedziałem się, że beta rozwiązuje mój problem.

Dziękuje za włożony trud! :)

Quest-88   15 #8 11.12.2013 18:22

@artymienek

Proszę bardzo. Miło przeczytać, że komuś przydają/podobają się moje teksty. :-)

arlid   14 #9 11.12.2013 19:47

Ciekawy wpis. Zazwyczaj ciężko znaleźć jakieś informacje od tej technicznej strony :) Fajnie widzieć, że pakiet rozwija się i ma się nadal dobrze :D Jestem ciekawy czy kiedyś w LO będzie możliwość aktualizacji bezpośrednio z programu.

Quest-88   15 #10 11.12.2013 20:35

@arlid

>Jestem ciekawy czy kiedyś w LO będzie możliwość aktualizacji bezpośrednio z programu.

Taka opcja jest bliżej niż myślisz. LibreOffice czerpie z dorobku OpenOffice (np. boczny panel), a zbliżający się AOO 4.1 ma posiadać w sobie mechanizm małych aktualizacji pod Windows.

Obecnie funkcja ta ma status "w trakcie", więc raczej na pewno się pojawi. Pytanie tylko czy i kiedy deweloperzy LO przeniosą to do siebie. Myślę, że jeśli się zdecydują, to użytkownicy ujrzą ją w wersji LO 4.4.

  #11 11.12.2013 21:43

A kiedy Microsoft zapłaci karę za bezczelne wpychanie swojego produktu do szkoleń unijnych?

Shaki81 MODERATOR BLOGA  37 #12 11.12.2013 21:54

Kapitalny opis, dawano takiego dobrego nie czytałem. Zastanawia mnie mnie jedno - a co na to OpenOffice?

Quest-88   15 #13 11.12.2013 22:27

Dzięki za dobre słowo Shaki. Co na to OpenOffice? Nic, bo to projekt. :P Ale są ludzie, którym niewsmak taki rozwój LibreOffice (np. Robowi Weir z IMB-a). Wiadomo, że chłopaki wezmą wszystko co uznają za sensowne i AOO właściwie nie ma się czym bronić. Np. niedawno ogłoszono integrację interfejsów IAccessible2 z AOO 4.1. Jak dla mnie, ten sam kod znajdziemy w LibreOffice 4.3. AOO może walczyć jedynie jakością eliminując drobne, ale denerwujące niedoróbki występujące u konkurenta albo idąc w zupełnie innym kierunku rozwoju. I widzimy, że LO uwalnia się od Javy, a IBM pompuje kolejne zasoby ludzkie w rozwiązania bazujące na Javie. Rynek zweryfikuje kto ma rację.

A jeśli chodzi o działania podobne do działań AMD, to nic nie słychać i nic nie widać. AMD przystąpiło do rady doradców przy TDF, a nie Apache. OpenOffice jest praktycznie martwy jeśli chodzi o udział w G SoC (od wielu lat), więc żaden student nie robi takich rzeczy jak A. Hunt.

Jak dla mnie ten projekt jest prawie martwy. Tylko obecność IBM-a utrzymuje go przy życiu, a i to się może szybko skończyć (myślę, że IBM znudzi się AOO do dwóch lat)

oprych   12 #14 12.12.2013 09:11

@Quest-88
A tak z ciekawości, porównywano może te wyniki z AOO albo MO? Warto byłoby mieć jakiś punkt odniesienia do tych danych.

Quest-88   15 #15 12.12.2013 09:26

Nie, nie wykonywano takich pomiarów.

oprych   12 #16 12.12.2013 09:55

Szkoda, bo mając takie podglądowe dane można byłoby się przekonać jak taka optymalizacja wygląda na tle konkurencji i czy faktycznie jest czym się chwalić :)

Odnośnie korzystania z funkcji WYSZUKAJ.PIONOWO, nie mogę sobie uzmysłowić, co takiego LO robił tydzień? Czy wyszukanie nawet w 10 tys. komórek tekstu jest aż tak czasochłonne?

A sam tekst jak zwykle warty przeczytania, można się z Tobą czasami nie zgadzać, ale i tak człowiek zawsze się czegoś ciekawego dowie

Quest-88   15 #17 12.12.2013 11:01

@oprych

Wiki AOO* nic nie wspomina o jakichkolwiek pracach nad optymalizacją Calca (w ogóle o nim nie wspomina), więc można przyjąć bezpieczne założenie, że Calc jaki był, taki też będzie w najbliższym czasie.

Różnice między OOCalciem i LOCalciem mogły do tej pory wyniknąć tylko z błędów popełnionych przez deweloperów LibreOffice (vide: WYSZUKAJ.PIONOWO), ale skoro się opamiętali i mocno poprawili, to nie sądzę, aby OpenOffice (poprzez zaniechanie) był bardziej wydajny.

Co do konkurencji ze strony Microsoftu to myślę, że i bez pomiarów wiemy, które rozwiązanie będzie szybsze. Poza tym etatowi deweloperzy LO to głównie użytkownicy Linuksa. Nawet w tekście jest informacja o platformie do testów (OpenSUSE), a kompilacje na Windows są robione dzięki kompilacji skrośnej (nie jest do tego wykorzystywany Windows). Raczej nie ma sposobu, aby porównać wydajność LO z MSO pod Linuksem.

* Zmiany w AOO 4.0
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Notes

Zapowiedziane zmiany w AOO 4.1 (już po odrzuceniu niemożliwych do zrealizowania celów)
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning

Jak widać, nigdzie nie ma Calca.

oprych   12 #18 12.12.2013 12:32

@up
Owszem masz rację, ale jak na razie podejrzewam, że 90% osób i pewnie niewiele mniej dla firm, interesuje właśnie to jak LO wydajny jest na Windowsie ;)

I dalej ciekawi mnie co było w tych komórkach, skoro LO potrzebował tydzień, a po optymalizacji dwa dni, aby po prostu je przeszukać?

oprych   12 #20 12.12.2013 12:58

Ja też nie :)
Po prostu ciekaw jestem co za dane można umieścić w arkuszu, aby system przeszukiwał je tydzień :) To po prostu taka chłopięca ciekawość :) Bez problemu jestem w stanie uwierzyć, że różne wersje excela/calca mogą pracować odczuwalnie inaczej z tym samym plikiem :) Sam używałem kiedyś skoroszytu, który miał od 8 - 10 MB i wszystkie makra, okienka chodziły dużo szybciej na MO 2003 niż 2007 lub 2010 :)

arlid   14 #21 12.12.2013 19:10

@Quest-88
fajnie słyszeć. Byłaby to może niezbyt wielka zmiana, lecz bardzo ciekawa i pomocna.

mikolaj_s   13 #22 12.12.2013 19:39

Bardzo fajny wpis, dzięki. Zobaczymy kiedy nowy LO pojawi się w Ubuntu. Na 12.04 jadę jeszcze na 3.5 ;)

Quest-88   15 #23 12.12.2013 20:04

@mikolaj_s

Spróbuj https://launchpad.net/~libreoffice/+archive/libreoffice-4-1

Jeśli chodzi o "pojawianie się w Ubuntu" to nie liczyłbym na rozsądek deweloperów. Oficjalna polityka TDF jest taka, aby do środowisk produkcyjnych wykorzystywać linię x.x.4, a w Ubuntu znajdziesz już x.x.0.

gilbert3   5 #24 12.12.2013 22:15

Dopóki LibreOffice nie dorobi się odpowiednika Outlooka, w co szczerze wątpię, bo nawet nie ma przymiarek do tego, to może się ewentualnie rozgościć w tych firmach, które oszczędzają na wszystkim: czyli na ludziach, na sprzęcie, na oprogramowaniu również. Żadne słupki określające wydajność wyszukiwania czy kopiowania nikogo nie przekonują.
Powiem szczerze i otwarcie - kto posmakował jak działa Microsoft Office (o ile używa w ogóle zawartych w nim funkcji), ten nie chce nawet palcem tknąć LibreOffice. Tym nie mniej LO wspaniała alternatywa do otwierania plików MS Office pod Linuksem, szkoda tylko, że nie ma wstążki :-).

greywolf   3 #25 12.12.2013 23:15

@up
Odniose się do wstążki - ludzie, co wy macie z tą wstążką? Ja używałem najpierw MSO 2003 a później próbowałem 2007 i 2010 i generalnie wstążka jest jak dla mnie niepotrzebna ;) jak dla mnie dużo lepszym rozwiązaniem jest pasek boczny z AOO i LO, jak dla mnie dużo lepiej współgra z ekranami 16:10 czy 16:9

  #26 03.02.2014 08:00

@greywolf

Zgadzam się!
W ekranach panoramicznych wstążka jest Be, ponieważ zabiera cenną wysokość obrazu, natomiast sidebar jest genialnym rozwiązaniem i super będzie jak LO przejdzie na sidebar.

Używam MSO 2013 i LO 4.2, więc mam porównanie. Ekran 14" w laptopie.