Given all of the rah-rah about QML and all of the calls I get about it I think it is time for a level headed appraisal. Unless you are developing only for a platform which already has to drag around the fully loaded 18 wheeler known as a javascript engine and it is actually able to do it, there is no reason to be using QML. You don’t give your battery powered contraption which has a CPU with a Chevy Chevette horsepower rating the task of pulling something designed to be dragged by an MRAP.
Yes, I’ve heard all of the arguments about separating the UI from the actual code. I’ve also seen all of the complaints and help requests on the Qt interest list relating to signal-slot problems, C++ QML wrapper classes, C++ QML back end classes and every other kind of technical difficulty. What I haven’t heard/seen much chatter about is the biggest issues with each and every scripting language out there.
- It’ a pig
- You cannot know until run-time if something is missing or the wrong version and the errors are generally written some place a production system cannot find.
- An OS which pushes out updates (i.e. Chrome and many/most idiot phones) can install a later version of some support thing which is incompatible with the version you built against, again causing errors to be written to places either never found or not easily found.
To some extent the last 2 somewhat apply to binaries with one glaring exception. When you fail to link to an external binary the OS tends to log it in a place which is easy to find. How many of you route your “QML Console” output to syslog in a production release?
I have ranted before about this Legacy design of shared libraries, but it deserves yet another rant. I will skip the mid-range and mainframe stories since most of you only know PC.
In the early days of DOS everything was statically linked into a single executable. The OS ran the disk, provided access to a memory range for video card, and managed memory, sort-of. With a 640K hard memory limit you couldn’t load too much. Then again, with a full height 10MEG hard drive you couldn’t store too much either.
Along came Linux, stealing half a page from the proprietary mid-range and mainframe play book, it introduced shared libraries. I say half a page because on the other half of the page was “proprietary, fully tested with all of our other proprietary software before you are given the option of installing it.” The shared libraries allowed for many more executables to run in memory at the same time. That, combined with all of the other hardware and OS tricks for accessing memory beyond 640K this was wonderful.
Now we are in an era of automatic updates where any kid with a keyboard can contribute something to your distro and if one of the higher ups doesn’t actually use anything it touches, little to no testing happens before it lands on your computer at 2 a.m. Now we are in an era where companies and average Joes wish to create a single executable which will run on Ubuntu, OpenSuse, Fedora, Cent, insert distro name here as well as version here, and the only way to do that is static linking. I have personally been bitten by this at a client site and seen so many emails/messages about it. A good many things, even in the world of Qt, cannot be statically linked.
In the world of software we have come full circle and static linking needs to become the norm again.
Compare this to the human story. In the day of our great great grandparents we were mostly an agrarian society. We ate lots of fresh fruits and vegetables, even cooked our own food. Despite the dangers of the life and time, those who didn’t smoke like chimneys and drink like fish were pretty healthy.
Next most people moved into cities. They ate tons of processed and fast food, became obese, diabetic and a rash of other things. Despite having a less dangerous life, even if they didn’t smoke or drink, they weren’t very healthy. They may have survived longer but they didn’t live longer.
Today we have governments and health experts telling us we need to eat and work like our great great grand parents. You can hardly go a week without hearing about a farmer’s market or a food desert. We have come full circle.
Recently I ported our little Pi program to QML. I just wanted to see if it was still the pig it used to be. Well, it looks like the pig gained weight and should be sent to market. Here are 2 nasty looking videos I shot with my tiny cell phone.
Hopefully you can expand to full screen and see just how far behind the screen updates. Even more important is the processor usage near the upper right corner of the display. When moving the mouse around it is over 90% peaking around 96%. That is going to suck a lot of battery! I have worked on projects where we tried to get 10 days of battery life for a portable device. This wasn’t 10 days of sitting on the shelf idle, but 10 days of taking patient readings through multiple shifts and wirelessly sending those results to a patient records system at timed intervals. With that kind of CPU utilization we would have needed the battery pack out of a Tesla, definitely not a portable device any longer.
The second grainy video is our original C++ application. Notice how the screen updates follow the mouse cleanly? Even more important, through all of the mouse movement the CPU utilization never went above 6%. A Pi typically has way more horsepower than most embedded systems. That 10 day battery life thing I mentioned earlier didn’t even have a GPU, just a CPU. We had to BLIT our images onto the display so the CPU could keep doing what it needed to do.
Don’t believe just how badly this ran on the Pi? Build it and run it yourself. You can download a zip here: piQml
