[Development] QTBUG-43096 - QML instantiation performance decadence

[Thiago Macieira]

On Saturday, 26 May 2018 14:01:59 -03 Jean-Michaël Celerier wrote:
> Well, you mention Nest thermostats : those actually run a Linux with 512 mb
> of RAM - more than enough for some QtCore goodness.

I said "similar to". Yes, there are some overkill devices for the needs they 
have. Usually because whoever made them decided to go for Java or HTML5 UI.

Another reason for 512 MB of RAM is that there are no smaller discrete memory 
modules. It's just not worth producing them in scale, so their price is 
actually higher than 512 MB, so no one produces them ... vicious cycle. 
There's a huge chasm between embedded RAM (order of a few MB) and discrete RAM 
(512 MB).

> > Which is why I don't think Qt has a role to play in these types of
> > devices.
> 
> This I don't understand. There would be so much to win in terms of code
> reuse - currently I have a QObject hierarchy for desktop and Qt UI
> interoperatibility and a raw C++ object hierarchy for embedded ; I'm just
> recreating the same stuff twice. It kills me that the embedded devices I
> use are powerful enough to run Python and Javascript interpreters but not
> some QObjects.

Qt is not going to run on a device with 16 MB of RAM. Period. Even running a 
regular Linux userspace is going to be tricky -- forget systemd at less than 
8 MB.

There are JavaScript interpreters for microcontrollers (see Duktape and 
Jerryscript). But those are designed to run on tens of *kilobytes* of RAM. You 
can't compare them to Qt, as they have special limitations to run that way. 
For example, neither implementation supports "eval".

Instead, compare Qt to a full JS interpreter, like V8. You need those 512 MB 
for it, otherwise you won't run comfortably. Ditto for Python. But Qt can run 
comfortably on 128 MB of RAM, possibly 64. QtCore+QtNetwork plus Websocket or 
OPC-UA or CoAP or other IoT protocols can definitely make do at 32 MB. 

But like I said, those devices don't exist because 32 MB is just not 
economical. Even routers and NAS are coming with 512 MB or 1 GB of RAM, for no 
technical reason at all.

> About the allocations, I don't know: running my app under heaptrack shows
> that QObjectPrivate is responsible for a great deal of those - way more
> than I would like. Besides, this is not so much a problem of memory than a
> problem of cache fragmentation. And in semi-powerful devices like Pi you
> can really feel these effects if you are trying to push them to the max.

That's because the Pi is, like you qualified, "semi-powerful". It's not 
powerful enough to make those limitations go away by using speculative 
execution and pipelining (which is why it wasn't affected by Spectre), but 
it's also big enough that people run complex software in it. In other worlds, 
it's "the worst of both worlds".

You should choose either a small microcontroller with a dedicated MCU-class OS 
that uses static memory allocation, or you should go for an actual powerful 
device that will hide those issues by doing other things while it waits for 
memory.

> Ideally, there would be something like QObject but which allows full
> constexpr or at least static-initialization; since embedded devices
> commonly have static object trees which could be built at compile-time. A
> QObjectLiteral of some sorts if you want, like QStringLiteral :p

Never going to happen, not in standard Qt anyway. Any such hacks would be 
specific to their particular use and hardly reusable. You're getting close to 
static memory allocation, which is when you decide at compile time that you're 
going to have N such objects and never more. That's how MCU-class OSes 
implement TCP/IP for example. They can have at most an configuration-time 
chosen number of simultaneous connections. If you try to start one more or if 
you receive one more SYN, it will fail.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center