Comparing Qt's QML vs. Enlightenment's EFL

[phoronix]

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

[Krysto]

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

[RealNC]

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

[zanny]

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.

[jumpr]

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.

[zanny]

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

[renox]

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

[TheBlackCat]

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.

[V!NCENT]

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

They realy need this, huh?

[jalyst]

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