Tomasz Olszak opublikował benchmark porównujący Qt Quick z EFL. Jest to pierwszy publicznie dostępny obszerny dokument na ten temat, zajmujący się pojawiającymi się niekiedy mitami na temat narzędzi, czy języków wysokiego poziomu. Porównane zostało zrealizowane na konkretnym przykładzie prostej gry Saper. Zanalizowane zostały wrażenia towarzyszące użyciu obu narzędzi (tu wyżej poziomowy Qt Quick ma w ocenie autora przewagę), rozmiar kodu źródłowego (obiektywna przewaga Qt Quick).

Kod Qt okazał się ponad dwukrotnie krótszy i ogólnie rzecz biorąc bardziej zrozumiały. Ponadto precyzyjnych badań zajmowanej pamięci i czasu startu aplikacji, dokonano na dwóch dystrybucjach Linuksa z różnymi procesorami i pamięciami masowymi.

Programista był zaskoczony szybkością, z jaką zaimplementował grę nie będąc ekspertem w Qt Quick ani od gier. Zaskoczyło także porównanie deklaratywnego języka QML z niskopoziomowym C stosowanym w EFL. Silnik Qt Quick podczas wykonywania, nie ustępował w istotny sposób wydajności EFL (niekiedy na 64-bitowej architekturze go pokonywał), a należy pamiętać, że Qt Quick stosuje wirtualne maszyny języka QML (do wykonywania animacji, efektów, zmiany stanów w GUI) i JavaScript (do realizacji logiki biznesowej). Kod EFL jest natomiast kompilowany do natywnego kodu procesora.

Testowany był Qt Quick 1 z Qt 4, więc autor wyraził też przekonanie, że Qt Quick 2 z niedawno wydanego Qt 5, cechuje się jeszcze lepszymi wynikami. Do testów stosowany był najnowszy stabilny EFL, a oba programy były uruchamiane pod niezależnym od obu toolkitów prostym menadżerem okien IceWM. Wszystkie programy testowe wraz z danymi zostały opublikowane, więc można je powtórzyć samemu lub dodać kolejne testy.

ŹRÓDŁOtolszak-dev.blogspot.com
Poprzedni artykułLinux Mint Debian Edition 201303
Następny artykułRed Eclipse 1.4 Elara Edition
Michał Olber
Interesuję się głównie sprzętem i działaniem jego pod systemami GNU/Linux. Testuję różne dystrybucje i robię recenzje. Interesuję się działaniem sprzętu pod Linuksem, dzięki czemu wiem, jaki zestaw komputerowy wybierać :)

26 KOMENTARZE

  1. Brawa dla Qt jeśli wysokopoziomowy język z wirtualną maszyną ma wydajność natywnego kodu. Jedynie zimny start jest ciut gorszy.

    • Kolega widzę dał się ponieść fantazji – w artykule był porównany tylko czas startu aplikacji ;)

      Ciekawe dane odnośnie pamięci, czyżby maszyna wirtualna lepiej współdzieliła dane pomiędzy procesami? Być może programiści EFL nie przyłożyli do tego wystarczającej uwagi? A może chodzi o to że testy dla 64bit przeprowadzone były z inną wersją EFL?

      Szkoda, że autor nie sprawdził skąd dokładnie wynika takie a nie inne zużycie pamięci – byłoby o wiele ciekawiej.

  2. aplikacje qml zajmują 2x więcej pamięci w porównaniu do efl, a to dla urządzeń mobilnych ma spore znaczenie. Podobnie jak zimny start, który dla urządzeń mobilnych ma większe znaczenie ni na desktopie. Poza tym fajnie było by zobaczyć jak wygląda wydajność dla urządzeń z procesorami ARM, bo qml i częściowo efl celują w telefony.

    • Jakaś magia to powoduje, czy może dysponujesz danymi? Może język C++ (wiadomo że nie)? Może typ int zajmuje 2x tyle (wiadomo że nie)? Z testu wynika raczej, że konsumowane zasoby są podobne.

      Na urządzeniach aplikacji nie dotyczy zimny start, bo biblioteki już są załadowane i cache wczytany po starcie systemu. Zakładamy, że stosuje się hybrydy kilku toolkitów, a najlepiej jeden spójny, np. Qt. Test dla zimnego startu pokazuje głównie ile jest zależności dla danego rozwiązania – im ich mniej tym większa szansa na szybszy start.

      Odnośnie czasu startu mowimy o 100-200 ms, do dalszego ograniczenia (wg komentarzy) dzięki preloading (http://tolszak-dev.blogspot.com/2013/02/simple-qml-vs-efl-comparison.html?showComment=1363668349161#c1451665518514927446). Poza tym duża aplikacja w QML nigdy nie jest ładowana cała. Ładuje się pojedyncze elementy (np. strony) przy pomocy narzędzia Loader (http://qt-project.org/doc/qt-4.8/qml-loader.html)

      Autorzy EFLa ucieszyli się z testu i widzę z komentarzy, że planowana jest powtórka dla niektórych ARM, np. z raspberry.

    • Zysk powinien być na czasie startu (brak konieczności kompilacji javascriptu przy uruchomieniu) i ilości zajmowanej pamięci (bo nie trzeba VM) jeśli dobrze rozumiem jak działa QML.

    • JS w V8 kompiluje się 2 fazowo. Najpierw jest szybka kompilacja bez optymalizacji. Potem dopiero włącza się agresywna. Szczególnie w często wywoływanych elementach programu.

  3. Według mnie coś jest skopane w EFL. Nie umiem zrozumieć tego w jaki sposób maszyn wirtualna może być szybsza od kodu natywnego?!

    Bodhi Linux zrobił na mnie pozytywne wrażenie swoją szybkością i dosyć ciekawym GUI. Niestety wersja z jądrem 3.7 nie bootuje na moim komputerze (jakiś bug).

    • Nie ma się co przejmować. Przeprowadź własne dochodzenie. Prawdą jest, że Qt ma mega wydajne i zoptymalizowane rysowanie (wydajniejsze niż szeroko stosowane Cairo), które w Qt5 jeszcze bardziej przyspieszyło.

    • Może być jeśli alokator jest kosztem lub są wycieki. Wiadomo od lat, że najlepsze są alokatory zoptymalizowane do konkretnego zadania. Dopiero ostatnio w EFL autorzy odkryli potęgę QString (implicitly shared string) i podjęli się napisania czegoś podobnego w gołym C ze wskaźnikami: https://phab.enlightenment.org/phame/live/1/post/

      Poza tym jeśli ktoś przetestuje samą wydajność animacji (w/w test tego nie robi) zaskoczenie może być o podobnym charakterze. Qt Quick od wersji 1 ma zoptymalizowaną konstrukcję sceny w SceneGraph, podobną implementację zaś z EFLa wycofano z powodu niestabilności (nie była dokończona).

    • To pytanie zadaj twórcom.
      Qt to dalej niszowe rozwiązanie, mimo wieloletnich obietnic Nokii. Profesjonalnie używane głównie do zapewnienia widoku aplikacji na Linuksie.

    • Wydaje mi się, że mniej niszowe niż EFL. A z tego co widać to Qt może mieć coraz większe znaczenie. Qt dostępne jest dla Windowsa, Linuksa, Maca, Solarisa, BlackBerry a także dla Windows CE, Windows Mobile, Symbiana. Jest też już port dla Androida, o którym niedawno tu pisano. Ubuntu pewnie też będzie wykorzystywać tą technologie. Więc dla mnie to trochę dziwne, że taki system jak Tizen się od tego odciął i tym mnie nie przekonuje. Ja stawiam na Mer i popieram również SailfishOS.

    • Tak, ale czy się integruje z każdym z tych systemów? Bo wygląd czy obsługa schowka i dnd to dziś za mało.

    • Nie.
      Obsługuje tylko niewielką część wspólną wszystkich systemów.
      Resztę trzeba dopisywać samemu.

    • Jakies przyklady tej wielkiej nieobslugiwanej czesci systemow moze podasz bym skojarzyl czy rozumiesz temat?

    • Pewnie większość firm tak pisze kod. Tylko nie wiem czy jest to aż takie fajne rozwiązanie, bo łatwiej byłoby napisać całe GUI w Qt i działałoby na wszystkich systemach.

    • Ha, od 2 lat nie ma już tam EFLa oczywiście może to być zaskoczeniem dla nieznających koreańskiego bo żadnej dokumentacji do tego po angielsku na tizen.org nie ma :) Używa się HTMLa i C++ z bada OS. W pewnej wersji jest manager okien Enlightenment dla X11, ale to jak wiadomo jest osobny program a aplikacje to też osobne programy. http://en.wikipedia.org/wiki/Tizen

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj