This is a non-issue and anyone who is worried about it is having a severe case of premature optimization.
As for the crazy contrived example they have provided: "Assume I receive 100,000 trades per second from some crypo exchange and if one trade triggers 100 signals than I have 10.000.000 signals per second that is something comparable with the maximum." - They'd have to process the incoming messages on a separate thread (or process) anyway, so they wont drop packets because of the event loop that also processes user input. Then update the GUI once every event loop tick because that's how frequently the UI gets updated anyway.
Is it really though? It's used in embedded systems. I wouldn't call those that can run Qt UIs microcontrollers.
https://www.qt.io/microcontrollers-st .
As per my old boss, the difference in prices when it comes to these microcontrollers and "less powerful" linux socs is negligible that it wasn't worth trying to target them. Not sure if/how the economics changed over the last 2-3 years either.
> Qt Quick Ultralite is designed to serve as a rendering engine for the application's graphical user interface (UI). Its implementation is different from the standard Qt, and it does not depend any Qt libraries such as Qt Core or Qt Gui. Hence Qt Quick Ultralite applications need to use standard C++ containers and classes instead of those from Qt. For example, instead of using QObject or QAbstractItemModel, Qt Quick Ultralite provides a simple C++ API to expose objects and models.
> It does not include the following from the Qt world:
> The Qt C++ APIs. The non-graphical modules such as Qt Core and Qt Network. The Add-on modules such as Qt Multimedia, Qt Bluetooth, and others Qt Addon Modules. The non-MCU embedded platforms such as embedded Linux or the mobile platforms.
https://doc.qt.io/QtForMCUs-2.1/qtul-integratecppqml.html
Which is kind of interesting ...
Qt signals are absolutely fine for like 99% of their usage.
I think the "This is a premature optimization" mindset is what leads to slow pieces of software that I like to avoid (React, Qt, electron). But I guess it's fine, as most users don't care as much as I do.
I think it's less true now, but I remember KDE (Qt-based) being slower and buggier than gnome (Gtk-based) a couple of years ago, just to cite one thing. It just felt like Qt-based stuff was in general more of a pain to use & heavier than GTK based stuff. It's really a matter of personal preference here and Qt is a nice project, just that I have some criticism here regarding performance choices. I feel like bad performance decisions tend to snowball and get multiplied when people make library choices and add their own performance issues on top.
Because you included it in a list that otherwise only contained web tech frameworks. It’s not clear to me why you think those are peers of Qt and implied to me that you think they are near equivalents.
What I'm trying to understand: are you talking about when you ask Fusion 360 to do something expensive the UI stops responding for a bit? I certainly see that, but it's not Qt that is the source of problems.
Do you work with huge models?
For hobbyist stuff at least Fusion is by far the least painful option, but the bar is set really, really low. FreeCAD is a gigantic clusterfuck to put it charitably (akin to using an awl to carve a drawing out of cardboard versus pencil and paper). OpenSCAD is neat but it really suffers because OpenSCAD is basically developed and maintained by a single person.
I just dislike people bashing technology for the wrong reason (like it being a "js framework").
In qt+qml usually you connect slots to signals in js, even if they are implemented in c++.
Now a virtual function call, a JIT compiler can devirtualize more often than an AOT compiler. But the vast majority of function calls in your typical C++ app are not virtual.
We're talking about Qt 'signals' though - they're sort of heavy-weight virtual call, reimplemented in C++, not regular function calls.
It should also be noted that Qt signals are far from the optimal way this can be implemented in C++. On top of that, C++ itself makes it more complicated than it needs to be by not providing a bound (to receiver) member function pointer as a primitive; but even then, this can be done in two indirections. A compiler for a language that supports such a facility directly - say, Delphi - can compile it down to a single indirection.
But again... a JS JIT could unroll that loop, leaving with just a couple of instruction per call and no loop.
Being mindful enough to identify when you're feeling the urge to optimize something too soon, will let you step back and optimize what will have the biggest impact once it's finished.
I have seen developers spend hours optimizing some functionality, pick the fastest technique, and it turned out by designing everything to work with their earlier optimizations they made the overall system much slower.
10x the latency of a virtual function call for a signal is very very small beans compared to where you're actually spending CPU cycles, for any reasonable software.
I agree that we shouldn't always think "this is premature optimization". However, we should focus our optimization efforts where they matter, and I really struggle to think of a place where signal latency is really crucial. In any well architected software that's going to be really rare and it makes sense to focus your efforts on optimizing other parts of the software, which seems to be what the Qt devs did.
Even if the callback were infinitely fast, if it's called 10e6 times per second, the work already can't take longer than 100 ns on average (10e6 * 100ns = 1e9ns = 1 second). So a more useful way to frame this would be in terms of the ratio of the callback overhead to the work done by the callback (both measured in time), but there's no mention of the latter.
In this particular case, this is a pretty obvious case of 'this is the wrong tool for the job', at least with the stated requirements. Also, at the point where you need to do something 10e6 times per second it's usually appropriate to think about how you might distribute that work across multiple cores.