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.

  • veramird

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

    • adrb

      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.

  • niko

    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.

    • jstaniek

      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.

  • MikolajS

    To by nieco przeczyło temu co wypisują http://trac.enlightenment.org/e/wiki/EFLOverview i stawiało pod znakiem zapytania sens rozwoju EFL. Pewnie gdyby użyć jako języka logiki aplikacji C++ wynik byłby bardziej na korzyść Qt

    • sprae

      To zależy co ta logika by miała robić i ile czekać na swoje dane.

    • MikolajS

      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.

    • sprae

      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.

  • Premislaus

    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).

    • sprae

      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.

    • jstaniek

      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).

    • adrb

      Po pierwsze to, że coś jest napisane w C lub asemblerze, nie znaczy że musi być automatycznie szybsze od czegokolwiek napisanego w języku wysokiego poziomu.

      Po drugie http://en.wikipedia.org/wiki/Just-in-time_compila

  • I teraz pytanie czy uzasadnione było powstanie Tizena, który w przeciwieństwie do MeeGo postawił na HTML +EFL zamiast Qt.

    • herr

      Systemy webowe są wymyślone po to by skuteczniej doić użytkowników :P

    • sprae

      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.

    • sprae

      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.

    • k.ra

      z dobrej integracji jest wlasnie Qt znane, nie?

    • sprae

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

    • k.ra

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

    • MikołajS

      "Tak, ale czy się integruje z każdym z tych systemów? "

      A co jest lepsze?

    • sprae

      Lepsze jest pisanie natywnych widoków z zachowaniem przenośnego modelu.

    • MikołajS

      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.

    • sprae

      Skoro tak uważasz to się ogłoś z tym. Zarobisz całkiem dużo jeśli to prawda.

    • xxd

      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

    • Jestem zaskoczony ;p A Ty znasz koreański? ;-)