Announcement

Collapse
No announcement yet.

Comparing Qt's QML vs. Enlightenment's EFL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Comparing Qt's QML vs. Enlightenment's EFL

    Phoronix: Comparing Qt's QML vs. Enlightenment's EFL

    For those developers looking for a technical comparison between Qt's QML against the Enlightenment Foundation Libraries (EFL), here's a comparison...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    This should put the argument that Ubuntu Touch should've used EFL to rest.

    Comment


    • #3
      It has to be said though: since this comes from a KDE dev, it has to count as biased.

      Comment


      • #4
        While I'm big on qt, I don't really get the point here:
        • QML is designed for rapid development, and JS is a script language, of course a shim style language + script language will be easier to write than C.
        • Minesweeper is barely computationally intensive, and most of the logic of QML is in the QtQuick runtime that interprets it. Of course performance will be similar in something that has no math intensive logic.
        • GUI apps barely ever have any performance overhead (properly implemented) anyway, because they are just user event handlers.


        I mean, it is reasonable to say "X wants to use EFL, here is a comparison of qml to efl in terms of performance and brevity of code" but it doesn't mean EFL is useless, if you like using it it is a perfectly reasonable platform to use. I personally prefer the benefits of qt + qml (cross platform, code brevity, ability to drop into C++ at a whim for performance) but to each their own.

        But comparing a native toolkit to a script toolkit seems a bit silly. The only takeaway is that, gasp, the QML runtime is well implemented that the overhead of parsing the files into Qt widgets isn't high and thus the apps perform similarly in a task that isn't very processor intensive and easy to render.

        Comment


        • #5
          Originally posted by zanny View Post
          The only takeaway is that, gasp, the QML runtime is well implemented that the overhead of parsing the files into Qt widgets isn't high and thus the apps perform similarly in a task that isn't very processor intensive and easy to render.
          This is exactly what the benchmark focuses on, and these are superimportant everyday qualities of software developer's work. Moreover the benchmark doesn't look like for data processing. Comparing large applications wouldn't be so easy because it's hard to make 2 large applications similar; it's easier to make 2 small but nontrivial applications that do simple typical things and uses fine share of features from the app frameworks.

          Comment


          • #6
            Originally posted by jumpr View Post
            This is exactly what the benchmark focuses on, and these are superimportant everyday qualities of software developer's work. Moreover the benchmark doesn't look like for data processing. Comparing large applications wouldn't be so easy because it's hard to make 2 large applications similar; it's easier to make 2 small but nontrivial applications that do simple typical things and uses fine share of features from the app frameworks.
            But he benchmarked his demos on an i5 and i7 - mid-high end CPUs that shouldn't be taxed by a hundred instances of minesweeper in almost any language, let alone popular toolkits. I like that it legitimizes my usage of qml for almost everything now (because I do love it) I'd just rather have seen the overhead of a qml/js only qt app vs one written natively (and EFL would have been a valid comparison for that...)

            Comment


            • #7
              Originally posted by zanny View Post
              But he benchmarked his demos on an i5 and i7 - mid-high end CPUs that shouldn't be taxed by a hundred instances of minesweeper in almost any language, let alone popular toolkits. I like that it legitimizes my usage of qml for almost everything now (because I do love it) I'd just rather have seen the overhead of a qml/js only qt app vs one written natively (and EFL would have been a valid comparison for that...)
              +1
              That's an usual issue with FOSS: developers like their speed-daemon computers and optimize for it, there is no "boss" to tell check to benchmark their software on 10-year old computers..

              Comment


              • #8
                Originally posted by zanny View Post
                But he benchmarked his demos on an i5 and i7 - mid-high end CPUs that shouldn't be taxed by a hundred instances of minesweeper in almost any language, let alone popular toolkits. I like that it legitimizes my usage of qml for almost everything now (because I do love it) I'd just rather have seen the overhead of a qml/js only qt app vs one written natively (and EFL would have been a valid comparison for that...)
                According to the comments someone is planning on re-running the tests on a rasberrypi.

                Comment


                • #9
                  Nokia drops Symbian (Qt) and Tizen is rocking the EFL.

                  They realy need this, huh?

                  Comment


                  • #10
                    Originally posted by V!NCENT View Post
                    Nokia drops Symbian (Qt) and Tizen is rocking the EFL.

                    They realy need this, huh?
                    Symbian != Qt, never did & never will, Qt was always used by more than just that.
                    As for the rest of your post, forming clearer sentences would help...

                    Comment

                    Working...
                    X