Blog OpenOffice.org Ninja opublikował przekrojowe porównanie prędkości jedenastu wersji OOo. W zestawieniu znalazły się wersje od 1.1.5 do roboczej D300m3, która zapowiada nadchodzące wydanie 3.0.
Statystyki objęły kilka podstawowych parametrów, takich jak czas startu i zamknięcia aplikacji oraz otwarcia pierwszego dokumentu (zarówno “na zimno”, jak i po “rozgrzewce”), przewijania dokumentu z góry na dół czy wreszcie eksportu do paru formatów.
Kiepska wiadomość: generalnie z wykresów widać, że po OpenOffice.org 1.1.5 sumaryczne czasy tych operacji utrzymywały się na zbliżonym poziomie, natomiast po wersji 2.2 wyraźnie rosną. Nieco lepsza jest taka, że na blogu ma się pojawić cała seria wpisów jak poprawiać wydajność pakietu.
Mam nadzieję, że 3.0 w wydaniu finalnym jednak przyśpieszy. Najbardziej znacząca jest w tym momencie prędkość otwierania dokumantów.
`
Ciekawe jak w tym samym zestaweniu wyglądaly by inne pakiety biurowe (KOffice, Lotus, Star Ofice, MS Office 2003, 2007…)
Bo koffice jest w c, a oo w javie. Java jest wolna, to niezaprzeczalny fakt. Bardzo źle się dzieję, że kolejna wersja jest wolniejsza od poprzedniej, źle to świadczy o programistach. Mam nadzieję, że albo oo przyśpieszy, albo ko dostanie nowe funkcje.
Nie tylko.
http://wiki.services.openoffice.org/wiki/Java_and…
oraz
"Uwaga: Po wyłączeniu Javy nie można korzystać z OpenOffice Base, korektora gramatycznego LanguageTool i innych komponentów napisanych w tym języku, takich jak autopilot raportów, sterownik JDBC, filtry XSLT, BeanShell (język skryptowy NetBeans) i Java UNO, filtry eksportu do Aportis.doc (.pdb) dla Palmow i Pocket PC, Word (.psw) format dla Pocket PC, odtwarzacza mediów, scalania korespondencji oraz wszystkich kreatorów we Writerze."
Z http://pl.wikibooks.org/wiki/OpenOffice.org/Szybs…
@rorio: "Java jest wolna, to niezaprzeczalny fakt."
:
Testy prędkości mówią coś zupełnie innego! Java jest szybka – prędkością dorównuje językom natywnym. Mówię to jako programista C/C++/Pascala/Delphi/PHP/Java/ASM(6502,x86,8051). Program w byte-code Javy jest KOMPILOWANY do kodu natywnego maszyny przez VM i dostosowany pod procesor na którym działa, więc może być nawet szybszy niż program w C skompilowany uniwersalnie. Optymalizacja końcowa przerzucona jest na wirtualną maszynę i bardzo dobrze! Java ma inny problem, który nieco ją dyskwalifikuje na desktopie a nie ma wielkiego znaczenia na serwerach, jest to ogromne zużycie RAMu w porównaniu z klasycznie skompilowanymi programami.
:
@quest: w OOo nie działa Base bez Javy, bo OOo Base używa Javowej bazy SQL (HSQLDB) do zapisywania danych. Swoją drogą jest to jedna z najszybszych baz danych na świecie. LanguageTool też jest napisany w Javie. Skoro coś jest napisane w Javie to czemu się dziwić, że bez niej nie działa? Cała reszta OOo działa bez Javy i nie ma z tym problemu. Taka duża aplikacja musi być natywna, bo VM Javy zużywa ogromne ilości RAMu co na wielu desktopach jest niemożliwe.
Dobra. w skrocie. Ten sam kod (dostepny jak ktos chce bo forum nie pozwala mi wkleic) napisany w 2 jezykach: Java i C++.
Kod wykonania przy uzyciu Java 1.6.0_05: 39.31s
GCC (-03): 16.01s
Intel C++ (-xB -fast): 11.52s
Wiec wyglada na to, ze Java wypadla ponad 2x wolniej nawet od kodu GCC bez optymalizacji na platforme…
@Vampire: kazdy wie ze java jest wolna i zzera pamiec, niestety najwieksi fanboye javy proboja ci wmówić, że bóg nas kocha, a mimo wszystko zsyła na ludzkość głód i cierpienie.
Zauważyłem coś ciekawego: ludzie, którzy programują w javie zawsze mówią, że jest piekielnie szybka. Cała reszta mówi coś zupełnie innego. Dziwne, prawda?
@vampire: wklejam moje wyniki Twojego testu.
GCC: gcc version 4.0.1 (Apple Computer, Inc. build 5367)
Java: java version "1.5.0_13"
:
Testy uruchamiane na Mac OS X 10.4 (mogę uruchomić na openSuSE jak chcesz), na MacBook Pro C2D 2.2 GHz.
:
Program w C++ kompilacja standardowa:
<code>real 0m15.409s
user 0m14.907s
sys 0m0.058s</code>
Program w C++ kompilacja -O2 :
<code>real 0m14.405s
user 0m14.278s
sys 0m0.053s</code>
Program w Javie, VM uruchomiona w trybie -client (domyślny):
<code>real 1m12.099s
user 1m11.343s
sys 0m0.302s</code>
Program w Javie, VM uruchomiona w trybie -server:
<code>real 0m12.113s
user 0m11.892s
sys 0m0.091s</code>
Jak widać program pod VM Javy uruchomionej w trybie server wykonał się o 2 sekundy szybciej niż wersja z optymalizacją -O2 w C++. Programy uruchamiałem jako argument polecenia time, mierzącego czas wykonania programu, co w przypadku Javie nie jest do końca sprawiedliwe, bo VM Javy wtedy jeszcze kompiluje byte-code na kod natywny, podczas gdy skompilowany program w C++ już działa. Na przyszłość: zanim ocenisz jakieś narzędzie warto je poznać!
Skad taka roznica pomiedzy client a server?
Czym ona jest spowodowana?
Narzedzie oceniam na podstawie domyslnych ustawien. Powinny byc jakies w miare sensowne. GCC z domyslnymi ustawieniami daje kod wykonujacy sie w 17.06s…
Dodam tylko że gdybyśmy mierzyli ilość zużytej pamięci operacyjnej to C++ byłby niezaprzeczalnym zwycięzcą. Oceniając prędkość wykonywania danego programu należy przyjąć zasadę, że język kompilowany jest szybki, a interpretowany jest powolny, C++ jest językiem kompilowanym, podobnie jak Java. Jak żółw jest python, ruby, PHP i inne języki interpretowane… chyba, że ktoś zrobi dla nich wydajny kompilator (może już istnieje?). C++ też można interpretować i tak wykonywany program będzie koszmarnie powolny! Co z tego, że w C++? Liczy się sposób uruchomienia programu, czyli droga jaką program przechodzi aby wykonać się na procesorze (na sprzęcie).
@vampire: Sprawdzę to jutro na moim stacjonarnym z Linuksem, wyniki z Maka są autentyczne. Ponadto nie uruchamiaj programów Javy z plików Jar, bo on wtedy musi się dodatkowo rozpakować. Z tego co widzę to używasz NetBeans, więc wejdź w katalogu projektu do podkatalogu build/classes i tam wpisz:
:
java -server nazwa_pakietu.NazwaKlasy
:
Moim zdaniem najlepszy test prędkości był by wtedy, gdyby wewnątrz programu przed alokacją tablicy zapisać timestamp do zmiennej i po zakończeniu operacji w pętlach zagnieżdżonych też zapisać timestamp i obliczyć różnicę. Wtedy wiemy ile zajęło samo wykonanie algorytmu, bez czasu samego uruchomienia programu i ładowania klas.
Nie musisz tlumaczyc mi roznicy miedzy kodem kompilowanym a interpretowanym ani czym jest kompilator 😉 To ze 90% pisanego przeze mnie kodu to C/C++ (pozostale 10% to Fortran77) nie znaczy, ze nie wiem co to jest bytecode ;).
Jesli chodzi o pythona to mozna tam osadzic skompilowany kod C++ — wowczas nabiera rumiencow 😉
Drugi test:
$ time java -server javaperformancetest.Main
38.840u 0.143s 0:39.25 99.3% 0+0k 0+0io 1pf+0w
Jak chcesz to moge test powtorzyc na AMD Opteron lub Intel Xeon 54xx.
W wolnej chwili dodam pomiar czasu. Java to "nie moj swiat" wiec musze zerknac w dokumentacje.
pgCC 6.0-8 64-bit target on x86-64 Linux
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2005, STMicroelectronics, Inc. All Rights Reserved.
To dystansuje zarowno kod generowany przez GCC ktory byl 2x wolniejszy jak i przez Java (3x wolniejszy).
Rzeczywiście pod Linuksem java wykonuje się wolniej w tym teście – nie wiem z czego to wynika. Chłopcy muszą jeszcze trochę nad tym popracować :-). Za to nie było takie przepaści przy server i client, czasy praktycznie takie same, co jest dla mnie dziwne.
:
Maszyna testowa: AMD Athlon X2 2.2 GHz, Linux openSuSE 10.3.
Java: java version "1.6.0_05"
GCC: gcc version 4.2.1 (SUSE Linux)
:
Java client (Time elapsed – czas wyświetlany z programu):
Time elapsed: 18,279
real 0m18.528s
user 0m18.425s
sys 0m0.076s
:
Java server (Time elapsed – czas wyświetlany z programu):
Time elapsed: 17,833
real 0m18.045s
user 0m17.997s
sys 0m0.052s
:
GCC:
real 0m12.556s
user 0m12.553s
sys 0m0.004s
:
GCC -O2:
real 0m10.319s
user 0m10.301s
sys 0m0.016s
:
GCC -O3:
real 0m10.879s
user 0m10.873s
sys 0m0.008s
:
Mam nadzieję, że po tych testach upadną mity o powolnej Javie :-). Polecam wykonanie powyższych testów w rubym, PHP czy pythonie.
:
@vampire: co do osadzania skompilowanego kodu w pythonie, to tak możesz w każdym języku, w Javie też. Z pascala też możesz wywoływać biblioteki napisane w C++ i vice versa :-). Ale to nie może być argument przy pythonie, bo nie możesz powiedzieć że python jest szybki, bo można do niego dołączyć kod natywny skompilowany z C++.
:
Na koniec się jeszcze powtórzę i powiem tylko że Java w teście zużycia RAMu była by wielkim przegranym, bo zużywa go nawet więcej niż interpretery. Uproszczona klasyfikacja języków programowania wygląda tak:
:
Kompilatory: duża prędkość, słaba kontrola nad programem, słaba przenaszalność, małe zużycie pamięci i jest nad tym kontrola
:
Interpretery: mała prędkość, duża kontrola nad programem, duża przenaszalność, średnie zużycie pamięci i jest mniejsza kontrola nad tym
:
Java VM: duża prędkość, duża kontrola nad programem, duża przenaszalność, duże zużycie pamięci i nie ma nad tym kontroli, VM kompiluje klasy do kodu natywnego w locie, i nie można jak w C co do bajtu obliczyć ile program będzie RAMu zużywał.
:
Pod pojęciem kontroli nad programem rozumiem kontrolę nad sytuacjami wyjątkowymi, w Interpreterach i Javie o wiele łatwiej szuka się błędów, niż w skompilowanym kodzie.
1. Pascal to jezyk kompilowany. Python to jezyk skryptowy. Lawe osadzanie skompilowanego kodu obiektowego w jezykach skryptowych po raz pierwszy pojawilo sie wlasnie w Pythonie. Perl potrafi wykonac modul ktory zawiera kod C ale jest duzo problemow z tym.
Poza tym praktycznie nie ma straty wydajnosci przy wykonywaniu kodu binarnego i laczeniu go z kodem interpretowanym. W Perlu bylo inaczej.
Co do Pascala to naprawde to nietrafiony przyklad. Wszystkie jezyki kompilowane na linuksie, ktore maja kompilatory zgodne binarnie z GCC potrafia zaladowac biblioteke napisana w dowolnym innym jezyku kompilowanym. To zalatwia GCC a nie jezyk. W ten sposob nie raz laczylem kod F77 z kodem C++.
2. O RAM nie mowilismy tutaj. To zupelnie inna bajka.
3. VM Javy pod linuksa jest powolna. NIe wiem jak to wyglada pod Windows. W kazdym z powyzszych testow byla conajmniej 50% wolniejsza od kodu natywnego!
Wiec nadal potrzymuje, ze przynajmniej na Linuksie Java jest wolna. I mowie stanowczo JAVA w znaczeniu jako ogolna technologia, NIE jezyk programowania.
4. Znow widze ze starasz sie mi wyjasniac roznice miedzy kompilatorem a interpretatorem. Prosze… zlituj sie. Szczegolnie z ta "klasyfikacja", bo o tym to mozna byloby nie jedna ksiazke napisac.
5 "Java VM: duża prędkość, duża kontrola nad programem" oraz "Kompilatory: duża prędkość, słaba kontrola nad programem". Sorry ale IMHO to co napisales nie ma sensu. W jakims sensie nie masz kontroli nad programem napisanym w C? Albo F77? Powiedzialbym ze masz o wiele wieksza kontrole niz w przypadku Javy, ze wzgledu na dostep do adresow pamieci wirtualnej systemu…
Debug to nie jest "kontrola nad programem". Poza tym proces debugowania wyglada dosc podobnie, jezeli ma sie dobra nakladke na debuger.
Ad 1. Osadzanie skompilowanego (binarnego) kodu było już w C64 w BASICu 🙂
Ad 2. Wspomniałem o RAM aby pokazać wady Javy, nie wychwalam tej technologii, ale nie lubię gdy ktoś powtarza mity.
Ad 3. Java jako technologia nie daje kontroli nad prędkością wykonywania kodu, o to dba VM. Jak widać w Maku działa całkiem nieźle, a te rozbieżności zaciekawiły mnie na tyle, że posprawdzam na innych OSach. BTW powolny to jest python czy ruby – wolniejszy 20 razy od analogicznego kodu w C.
Ad 4. OK sorry – wyraziłem tylko swoją opinię
Ad 5. Nie mówię o debugowaniu, tylko o szukaniu błędu gdy u klienta wysypie się program, czyli tam gdzie nie masz debugera i innych narzędzi. Java w razie problemów zostawia pełny stacktrace, z nazwami plików i numerami linii kodu, oraz opisem błędu. Jest to tak wymowne, że w 99% przypadków od razu wiesz co się stało. Program skompilowany klasycznie, np. z C/C++ wywali segmentation fault, czy "program wykonał nieprawidłową operację" i bądź tu mądry i pisz wiersze…. niestety w dużej większości przypadków to niczego nie mówi a szukanie błędu na tej podstawie jest prawie niemożliwe. VM Javy dodatkowo ma możliwość uruchomienia programu z otwartym portem na debuger i możesz podłączyć się zdalnie do innej maszyny i debugować cały program. To wszystko jest out-of-the-box, bez kombinowania. Dlatego uważam Javę za bardzo dobry język dla biznesu, na programy serwerowe, gdzie potrzebna jest duża prędkość, niezawodność i szybkie szukanie błędów. Ze względu na duże zużycie RAMu nie polecam Javy na desktop, choć powoli ma to coraz mniejsze znaczenie.
@vampire: Błędu się najlepiej szuka na maszynie na której on występuje, bo w wielu przypadkach nie ma czasu na odtwarzanie bliźniaczego środowiska do testów. Bardzo często błąd występuje przy konkretnej konfiguracji środowiska, którego skonfigurowanie może zająć nawet kilka dni, a czasem jest niemożliwe (np. aplikacja współpracuje z drogą centralą telefoniczną, której firma sobie nie kupi tylko po to aby odtworzyć błąd). Pracowałem wcześniej w firmie, w której było kilku upartych, programujących aplikacje serwerowe w C++. Jak doszło do konieczności znalezienia i naprawy błędu to ja to robiłem w małą chwilę a oni się naprawdę długo męczyli. Ponadto moje programy w Javie nie miały tak wielu błędów jak te w C++, bo Java w pełni kontroluje to co program robi i nie nadpiszesz sobie wskaźnika np. zapisując poza rozmiar tablicy (dostaniesz IndexOutOfBoudsException), więc wychwytujesz takie błędy natychmiastowo, zanim progz trafi do klienta. W C++ zapisując pod index tablicy (lokalnej) którego nie ma piszesz po stosie wątku, i póki mieścisz się w jego ramach nadpisujesz sobie pamięć, a program szaleje – takie błędy naprawdę trudno się szuka. Jest jeszcze wiele innych zalet Javy dla biznesu, np.: zastaw bibliotek standardowych jest dość bogaty: JDBC, wątki, sockety, obsługa protokołów na warstwie TCP (np. HTTP, FTP), obsługa URLi, SSL, zunifikowane API obsługi strumieni … i nie ważne na czym piszesz i kompilujesz program, ważne aby klient miał JavaVM. Ja np. piszę programy na Linuksie i Maku, a uruchamiam na Windowsach i Linuksach – nie sprawia mi to różnicy. Wbrew pozorom to też ważny argument bo pozwala mnie jako programiście używać takiego OSu jaki mnie bardziej odpowiada … jakoś nie wyobrażam sobie pisania, testowania softu w C++ na Windows pod Linuksem.
wow. Gdyby pojecie "software engineering" bylo mi zupelnie obce to moze bym teraz doszedl do wniosku, jaka to wspaniala jest java bo pozwala aby quick hack przemienil sie w wytestowany program. To co opisujesz to jakies partyzanckie metody rozwoju oprogramowania. Jak mozna nie miec srodowiska testowego identycznego z tym u klienta? Albo szukac bledow na maszynie roboczej klienta? Nie do pomyslenia. Pochwal sie co to za firma tak robi — moze ktos z czytajacych nie popelni bledu kupujac tego typu produkt.
Gdybym nie wiedzial jak to wyglada w centrach rozwojowych kilku z wiekszych koncernow w branzy telekomunikacyjnej oraz IT to bym naprawde uwierzyl, ze tak to powinno wygladac.
Jedyne z czym sie zgodze to duza ilosc bibliotek w Javie.
Co do testowania oprogramowania na wielu platformach. Juz widzialem programy w Javie dzialajace pod Linuksem, nie dzialajace pod Windows. Ale nie o tym chcialem pisac. Raczej o tym, ze standardowe procedury testow wymagaja aby oprogramowanie bylo testowane na platformie na ktorej bedzie uruchamiane… Tego chyba komentowac nie musze.
To ze Twoj kod mial mniej bledow niz kod C++ oznacza tylko tyle, ze grupa testerow testujacych kod C++ za przeproszeniem "dala ciala", oraz ze byc moze grupa developerow byla odrobine slabsza niz ta w ktorej Ty pracowales.
PS. Co do pisania poza zaalokowana pamiec w C++. Jest to mozliwe, ale od tego sa wlasnie testy, zeby to wylapac. Slowo kluczowe do nauki na dzisiejszy wieczor: valgrind.
Dodam cos jeszcze. Rozmawiamy tutaj o predkosci kodu. Nie o ilosci bibliotek ani efektywnosci w zarzadzaniu pamiecia.
Jezeli chodzi o dyskusje nt. wyzszosci jednego jezyka nad drugim pod wzgledem zastosowan, to najpierw nalezaloby sprecyzowac konkretne zastosowanie a pozniej o tym rozmawiac. Tak jak Java ani C# nie nadaja sie do analizy numerycznej (np. symulacje) tak np. C srednio nadaje sie do duzych programow uzytkowych z interfejsem graficznym. Nie znaczy to oczywiscie, ze nie jest mozliwe stosowanie tych jezykow i do takich zastosowan ale po prostu sa do tego optymalniejsze narzedzia pozwalajace uzyskac dany efekt szybciej, latwiej, itp.
A wracajac do BASIC i C64.
Zerknalem na: http://en.wikipedia.org/wiki/Commodore_BASIC
Jedyna wzmianka o laczeniu z kodem innym niz BASIC jaka znalazlem to:
"Programmers also often wrote speed-critical sections of a program in 6502 assembly language and executed them from BASIC using the SYS command."
Nie ma ani slowa o mozliwosci laczenia BASIC z jakimkolwiek jezykiem wyzszego poziomu niz assembler, a chyba o tym rozmawialismy.
czas uruchamiania sie OO.org pod Windą jest przynajmniej 2 razy dluzszy od tego z wykresu… Dlatego windziarze mowia ze OO jest zołwiem w porownaniu z M$ office i maja racje.
Ten test choć rzuca jakieś światło, to nie jest wiarygodny. DEV300_m3 to staroć, już w tej chwili są kompilacje oznaczone *m_15, a w każdym kolejnym snapshocie usuwany jest zbędny kod a niezbędny jest optymalizowany.
Co w nim niewiarygodnego? Pisza ze m3 jest wolniejszy i nic poza tym…
Dodatkowo napisali ze m3 jest stary i ze nie mogli przetestowac
nowszego. Faktycznie, bezczelnie klamia 😉
Nie ma sensu porównywać ze Scribusem – to nie są programy z tej samej kategorii. Używam na codzień OO.o 2.4 (na Windzie). Prawda, demonem szybkości nie jest, ale mi wystarczy i jest za darmo. Niestety, obawiam się, że w wersji 3.0 niewiele się zmieni. On ładuję się przy uruchamianiu programu, a nie systemu (chyba, że włączymy Quickstarter). Poza tym dochodzą nowe funkcje, a jak wiadomo, wszystko waży.
Jest spora szansa, że przyspieszy. A to z powodu systematycznego usuwania locków w kodzie. Stary OOo był w pełni jednowątkowych, czego skutki odczuwalne są do dzisiaj np. przy otwieraniu dokumentów z osadzonymi obrazkami z internetu. Każdy obrazek musi zostać odpytany i dzieje się to w tym samym wątku, co obsługa UI. Przez to OOo przez większość czasu nic nie robi, gdy interfejs jest w stanie nieaktywnym.
A poza tym część z kodu jest od wersji 2.4 wykonywana na karcie graficznej 😉
(myślę o kosmicznych przejściach slajdów w OpenGL w linuksowej wersji OOo)
A właśnie, by mogli poprawić ten ko(s)miczny czas reakcji na wciśnięcie klawisza przy pokazie prezentacji. Bo zanim odpali się przejście (dowolne – zwykłe albo 3d), trzeba czekać przynajmniej 2 sekundy. Nie muszę chyba mówić, że w MSO czas reakcji jest niezauważalny
No w sumie to wydaje mi się, że Oxygen Office to to samo, ale z dodatkami, więc dlaczego miałby działać szybciej?
"Oxygen Office Professional to bezpłatny pakiet biurowego OpenOffice.org. Ta rozszerzona wersja zawierająca nie tylko wszystkie elementy pakietu OOo tj. Writer, Calc, Impress, Draw, moduł symboli matematycznych Math, ale też około 3000 zdjęć i klipartów oraz 90 dodatkowych nowych czcionek. Pakiet zawiera moduł integracyjny OOoWikipedia do bezpośredniego przeglądania tresci Wikipedii w trakcie pracy z dokumentami OOo."
[źródło: http://www.programypc.pl/oxygen;office;profession…
Jest moduł do symboli, do Wikipedii, nowe czcionki itd.
Na zdrowy chłopski rozum, to powinno chodzić wolniej.
Czy ktoś ma doświadczenie z tym pakietem?
(na razie zostaje przy OO.o 2.4, ale z niecierpliwością czekam na 2×3.0, czyli OO.o 3.0 i Fx 3.0 :))
Pozdrawiam
W takim razie trzeba przejść na Lotusa 😛 ponoć lepszy ale nie wiem jak z prędkością. Zapewne podobna. Ciekawe czy wyjdzie kiedyś distro z zainstalowanym standardowo Lotusem?
Lotus ma w opcjach możliwość przyspieszania kosztem wiekszej ilości zużytej pamięci. Na moje oko przyspiesza to troche przewijanie dużych dokumentów. Niestey równania napisane w OO całkiem sie psują, są puste kwadraciki jak sie je edytuje to zawartość niby jest i czasem sie pojawia a czasem nie ( po edycji ).
Tego typu pasjonowanie się szybkością otwierania sie wydaje mi sie bez sensu. Ile procent czasu pracy z dokumentem zajmuje otwarcie dokumentu ? 0,0001%
Ważna jest funkcjonalność.
Ja używam OO i nie narzekam
Ale już szybkość przewijania dokumentu jest bardzo istotna, przy dużej ilości grafik, równań, tabel po kilku/kilkunastu minutowej pracy OO potrafi przwijać jedną strone na sekunde a nawet kilka sekund trzeba czekać!. A mam 3GB ramu i amd x2 4.8.
Nieraz chce się tylko szybko przejrzeć jakiś dokument i wtedy czas zimnego startu do 2 sekund to pożądana cecha. Nie każdy otwiera dokument żeby edytować go przez godzinę.
Kilka miesięcy temu próbowałem przenieść arkusze kalkulacyjne mojego taty z MS do OO. Niestety, nie udało mi się. Olbrzymie dokumenty otwierały się tak godzinami. Bardzo mnie to zasmuciło… Mój tata dalej używa MS. Nie jestem fanem MS i dlatego z przykrością przyznaję, że Excel od początku swego istninia jest produktem rewolucyjnym. OpenOffice, KOffice, Google Docs są za to bliższe mojemu sercu.
Heya i am for the first time here. I found this board and I find It truly useful & it helped me out much. I hope to give something back and aid others like you aided me.
Simply wish to say your article is as astonishing. The clarity in your post is simply cool and i could assume you’re an expert on this subject. Fine with your permission allow me to grab your feed to keep up to date with forthcoming post. Thanks a million and please carry on the enjoyable work.
My brother recommended I might like this web site. He was entirely right. This post truly made my day. You cann’t imagine simply how much time I had spent for this information! Thanks!
Dodaj komentarz