Page 1 of 2 12 LastLast
Results 1 to 10 of 12

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,136

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

    http://www.phoronix.com/vr.php?view=MTMzMTI

  2. #2

    Default

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

  3. #3
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,798

    Default

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

  4. #4
    Join Date
    Dec 2012
    Posts
    553

    Default

    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.

  5. #5
    Join Date
    Feb 2013
    Posts
    6

    Default

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

  6. #6
    Join Date
    Dec 2012
    Posts
    553

    Default

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

  7. #7
    Join Date
    Mar 2012
    Posts
    83

    Default

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

  8. #8
    Join Date
    Feb 2011
    Posts
    1,246

    Default

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

  9. #9
    Join Date
    Aug 2009
    Posts
    2,264

    Default

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

    They realy need this, huh?

  10. #10
    Join Date
    May 2007
    Posts
    327

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •