Qt performance
-
I was just going through the following link. "http://blog.algolia.com/need-performance-on-mobile-use-c-cpp/":http://blog.algolia.com/need-performance-on-mobile-use-c-cpp/
I was wondering whether apps done with Qt can be faster on ios and Android than apps done with their respective native apis (Objc and Java). There should be some performance loss from signals and slots. But still it should be faster. What do you think.
-
Depends on your coding skills, expertise in Qt/ Android SDK, overall app design etc.
In general, C++ and Qt will be faster, but that does not mean it's the best solution in all cases.
You don't need to use signals and slots if you don't want to - it's just a great but optional addition to C++. And in Qt5, signal and slot mechanism got faster + there were MOC optimisations on Linux (roughly 10x increase in performance, IIRC. Some of it applies to Windows, too, but not that much). You gain even more if you use clang and C++11.
-
Yeah, I agree. Also, in "this talk":http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C Herb Sutter argues that C++ seems to gain traction again, and not only on the mobile platforms that have one by one made native code possible (again). Interestingly, Qt seems to be moving in the opposite direction, where QML is pushed as the way to go for mobile. Even today, I read people on the development list argue about that one should just use QML to build iOS apps. Let's hope only a thin UI layer was meant by that...
-
[quote author="Andre" date="1363095352"]Even today, I read people on the development list argue about that one should just use QML to build iOS apps.[/quote]
That surprised me as well. And all this while QtWidgets are available for Android.
QML is still ultra cool in my opinion, though. I do agree it should get a decent C++ API and Widgets would benefit from getting some love, too.
-
[quote author="sierdzio" date="1363097022"][quote author="Andre" date="1363095352"]Even today, I read people on the development list argue about that one should just use QML to build iOS apps.[/quote]
That surprised me as well. And all this while QtWidgets are available for Android.
QML is still ultra cool in my opinion, though. I do agree it should get a decent C++ API and Widgets would benefit from getting some love, too.
[/quote]Qml is fine for doing UI. But on many lab blogs espacially in the Nokia days, more emphasis was given to Qml / JS and some statements that vaguely suggest that c++ is not needed. Either there is a real plan to make Qt a scripting thing, in the long term or these people are thinking only of those trivial applications which put data on screen from some web service. C++ is an unfortunate language. Everytime somebody come up with a new language they start by bashing c++. I hope Digia keeps Qt as C++ framework.
-
[quote author="Jayakrishnan.M" date="1363163268"]I hope Digia keeps Qt as C++ framework.[/quote]
Haha, quite funny people persist in saying that. Qt is C++. All the stuff that makes Qt is c++, and it will stay this way. In discussions any suggestions that we QMLify base Qt classes (like QDir, etc.) are rejected straight away. Performance and quality is still deep in Qt coding philosophy, don't you worry.
QtQuick vs. QtWidgets is a big problem, though, that certainly is true.
-
You gotta love the devotion of some people to their favorite thing and its power to distort reality:
bq. Sorry, but did you try the Mono for Android? I mean performance is obviously relatively comparable to C++
And then...
!http://www.codeproject.com/KB/cross-platform/BenchmarkCppVsDotNet/NumericCodeArm.png(arm)!
As for the impact of Qt - all it takes is to not do stupid things in tight loops. Signals and slots may be slower than normal function calls, but those aren't intended to be used in performance hotspots anyway.
I am a little more worried for QML and JS bindings, which are light on desktop machines, but wimpy mobile platforms combined with the very tempting binding may prove to be a bottleneck. Luckily ARM cores have grown in power significantly the last iteration.
-
All the stuff that makes the Unity game engine is c++. Still developers can't create Unity apps in C++. Will Qt go the same way in future ? Is it the real plan ? That is my concern. It is not about what language Qt is written in, but what language apps are created. Most probably I'am wrong and Qt will stay a c++ framework. But I got the negative impression from some blogs, including lab blogs. One of the selling points of the frameworks is being easy. C++ do have the perception of being less productive. So frameworks choose some scripting languages which have the perception of being easy. I guess that is the reason for the big push for scripts. With a good framework c++ can be as productive. I don't know how many people will agree.
-
C++ will simply become a language to extend Qt. There is slim chance that QtQuick will get a native API somewhere in the distant future. Lambdas can be used for binding at lower performance cost, one only loses the ability to test run the code without compilation, but some LLVM JIT powered solution could easily reduce the waiting time to non-existent. That would be the smart direction for Qt to take after the QML fuss dies down.
-
QML is much more touch oriented and polished than QWidget s. So its the way to go as far as mobile and tablets are concerned. Believe me, most of the mobile (or tablet) app developers are indy and novice, and belong to the generation of Managed Languages like Java or C#, whom eventually will not have enough exposure to C++. So it will not be sensible to scare them away with pointers, memory allocation, copy constructors and stuff.
So I prefer kids having fun with the bling thing ;-). While the Qt developers will still use C++ for heavy tasks. When I was using QML for a mobile app, I had to use Qt Native Threads and some model classes to extend the functionalities of QML. So when people require more functionality than what is offered in QML, then C++ is their option. This is what I feel.
-
Moreover, there are other alternatives for people (who don't wanna learn C++ or think its a pain to allocate and de-allocate memory by themselves) to choose. So lets not make them prefer those things against Qt. If they really want to code in C++, then there is nothing restricting them from doing it. After all, a QML Rectange is a QDeclarativeRectangle C++ class.
-
[quote author="raja26" date="1363167852"]QML is much more touch oriented and polished than QWidget s. So its the way to go as far as mobile and tablets are concerned. Believe me, most of the mobile (or tablet) app developers are indy and novice, and belong to the generation of Managed Languages like Java or C#, whom eventually will not have enough exposure to C++. So it will not be sensible to scare them away with pointers, memory allocation, copy constructors and stuff.
So I prefer kids having fun with the bling thing ;-). While the Qt developers will still use C++ for heavy tasks. When I was using QML for a mobile app, I had to use Qt Native Threads and some model classes to extend the functionalities of QML. So when people require more functionality than what is offered in QML, then C++ is their option. This is what I feel.[/quote]
So what about objective-c ? what about Symbian c++, Android NDK ? I guess embedded devs would be more suitable as mobile developers than web devs who are mostly experienced only in managed languages. Even for Android, they eventually had to provide the NDK. Most of the mobile devs are not novices. J2me / Symbian c++ was available from around 2003. So I guess most should know c++. Being novice, doesn't mean one is not exposed to c++. Most Btech / MCA courses have c\c++ in their cariculum. Qml is more touch oriented, you are true there.
-
The compiler manages the memory for you when developing with XCode. Symbian C++ days are when I had Nokia 6600 and 3230, even by the time there were PyS60 and m-shell available as easy alternatives. By the time I had my E63 Qt emerged for Symbians, only when I started to develop real apps for mobiles. Do you think atleast 100 devs are using Symbian C++ to develop mobile applications, today. I don't think so. And the Android NDK, when you download the NDK itself, Google would suggest you to use SDK and use NDK only when you can't do it with SDK.
I'm not sure about Android NDK usage, may be for hardcore Graphics applications.And regarding the curriculum C++, the real world programming is not just about
@
int i = 100;
int *j = &i;
@believe me, most of the Curriculum C++ is just this. I finished my B.Tech I.T in 2011. I am a die hard C++ fan and I did my Final year project in Qt C++ for Symbian (no QML was there at that time), and none of the other students did it in C++. Everyone else used VB, C#.NET and Java, TCL, etc.
After joining an MNC, I have started to code in Ruby and my leisure hours are being spent with C++. Still I feel like I need to learn a lot more in C++. So don't think that Novice developers, even with exposure to C++, will create better C++ applications.
-
[quote author="Jayakrishnan.M" date="1363169309"]
[quote author="raja26" date="1363167852"]QML is much more touch oriented and polished than QWidget s. So its the way to go as far as mobile and tablets are concerned. Believe me, most of the mobile (or tablet) app developers are indy and novice, and belong to the generation of Managed Languages like Java or C#, whom eventually will not have enough exposure to C++. So it will not be sensible to scare them away with pointers, memory allocation, copy constructors and stuff.So I prefer kids having fun with the bling thing ;-). While the Qt developers will still use C++ for heavy tasks. When I was using QML for a mobile app, I had to use Qt Native Threads and some model classes to extend the functionalities of QML. So when people require more functionality than what is offered in QML, then C++ is their option. This is what I feel.[/quote]
So what about objective-c ? what about Symbian c++, Android NDK ? I guess embedded devs would be more suitable as mobile developers than web devs who are mostly experienced only in managed languages. Even for Android, they eventually had to provide the NDK. Most of the mobile devs are not novices. J2me / Symbian c++ was available from around 2003. So I guess most should know c++. Being novice, doesn't mean one is not exposed to c++. Most Btech / MCA courses have c\c++ in their cariculum. Qml is more touch oriented, you are true there.[/quote]
Embedded devs and not web devs?? I am just looking at a world where everyone thinks that HTML5 is the answer for everything. I can promise this, any good UX developer can develop a good mobile app with HTML5, CSS3 animations and some cross platform tools like Sencha or jQuery mobile.
-
Symbian c++ is out now, I agree with that. Symbian c++ and J2me were standards for mobile development in the pre-iPhone era and we had done a lot of apps in these two. So I was somewhat disappointed at your comment that most mobile devs are novices not familiar with c++. ARC started from ios 5, before that we had to do manual memory management. The c portion of the ios sdk still need manual memory management. So mobile apps needn't be easy as a lot of people seem to think. I guess that is the source of a lot of complaints. Many people approach it with the mindset, it is a mobile app, it should be easy and once they start development they find that is not the case, and then they blame the tools, technologies etc.
You say you are a die hard c++ fan. There are lots of others like you. You have good company here. I guess you have good programming skills, and hence your love for c++. Less gifted ones, flock to things that seems easy, like .Net etc. Apps can be much more than the UX depending upon the requirement. Everyone thinks Html5 is the future. That doesn't mean that is going to happen. Even from a UX point of view and from efficiency point of view, native apis are better for mobile apps than web apis and embedded devs are better at native development because of their experience with resource constrained programming. Not all apps can be developed by html5/js and those that can be developed, are in most cases not as well performing as native apps. In mobile, performance affects the UX. So performance is very important. The issues with web apis prompted Facebook to rewrite their app as fully native. Html5 has its place. But it is not the answer to everything.
-
I am telling this because I have tried to convince people to use Qt(of course QML as UI) once in a small organisation where I developed an Android application and in the MNC where I am working now. I'm working in a Lab so they are ready to choose different frameworks rather than sticking to so called enterprise frameworks. Both times they said that it would be difficult to find good C++ mobile devs so they rejected. In that small organisation, I even produced a working prototype in a couple of days using QML, which was much more elegant than the Native Java application. So don't think that QML will take over C++, QML is C++, with a QML parser written in C++ :-)
-
The reason may be that all those Symbian c++ \ Qt \ j2me mobile devs may have migrated either to ios or Android and they may be working with objc or Java now. As it stands, c++ is not the main language in both the leading platforms. Once Qt for ios and android is released, things may change. With Qt you are no longer confined to being a mobile developer, since Qt works across domains. Objc devs can comfortably switch to Qt. Old symbian c++ / Qt symbian devs can return to Qt. Even the Java devs can easily learn Qt if they are not 'afraid' of pointers.
