[Development] QTBUG-43096 - QML instantiation performance decadence

[Richard Weickelt]

> 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".
I wonder if those tiny devices with tens or even hundreds of kilobytes RAM
running Jerryscript would be already sufficient for a "QML light". I am not
talking about QML GUIs, but rather simple sensor/actor applications
consisting of few state machines and using one of the 1001 available
communication stacks.

MCU vendors usually offer and praise their own C SDKs, but my experience so
far is that it can take a very long time to achieve even simple applications
and one has to write either a lot of boilerplate code or use fragile and
obscure tools.

QML has some powerful features that feel like a quantum leap when compared to C:
- property bindings
- easy component composition
- signals, signal handlers
- ...

If we had nice QML modules like Qt Bluetooth and Qt Sensors available for
tiny devices, I believe that application development would become very
simple and convenient. I am making a few assumptions here:

- the whole application structure would be static, no dynamic loading
  of components
- bindings are resolved at build-time.
- the application would be compiled to bytecode on the host before
  being flashed onto the target
- the back-end of those modules would most likely not be Qt
- it would be possible to deduce, which features the QML
  application actually uses so that unused functionality can be
  dropped at build-time.

I would be interested in other opinions. Maybe I am on a completely wrong
track here.

Richard