7 ms·
Given that signals are primarily for interaction with the outside world, (eg user action), 10x slower than the likely optimum seems perfectly fine, no? How many
by skrebbel 4y ago
Given that signals are primarily for interaction with the outside world, (eg user action), 10x slower than the likely optimum seems perfectly fine, no? How many times per microsecond do you expect a user to click that button?
I guess what I'm saying is, the example feels contrived.
- windows_sucks 4y ago"onMouseMove" is a user signal that you would want to be fast. also signals should be used for more than just user input interactions, like "download progress" etc..
- ehutch79 4y agoWhat are you doing with onMouseMove that would be perceptible to the user at higher than 60fps, or even 120fps?
- windows_sucks 4y agonothing but if you want to do something, say even at 1fps, you need to enable the signal to fire in the first place.
- dekhn 4y agoI wrote an interactive QtPy program- it receives video frames over the net and allows the user to interact (steering a microscope) in real time. I use millisecond timers (which generate signals delivered to slots) all the time. After doing a bit of tuning I was able to steer the microscope with no visible latency, which means I'm handling user events at ~25FPS or higher and not seeing any high variances. The only problems I have are when the handler that receives a signal takes longer than I have budgeted (IE, more than 1000/25).
- Quikinterp 4y agoDrawing perhaps?
- jonhohle 4y agoDrawing only happens (at most) once every 4ms. I’m not aware of any modern display technology that allows you to manipulate a frame buffer during the display interval (unlike CRTs which could be manipulated during a scan). The retro gaming community is obsessive about input and display latency and even there anywhere between 5-16ms (16ms being one frame of 240p content) is considered acceptable for even the most hardcore twitch response games. That’s not saying that other processes aren’t happening faster than that, just that human input and subsequent visual feedback maxes out somewhere between 200-300 times per second and for the vast majority of humans, it is far, far lower.
- mattkrause 4y agoHumans are even slower than that. If you measure the response of individual photoreceptors, it takes 25-50 ms to peak after a flash of appropriately-colored light; the precise number depends on the color and intensity of the light. After that, the signal still needs to propagate through a bunch of visual brain areas, and then even more needs to happen to somehow influence behavior. With everything tuned just so, you can complete that whole process in 100 ms or so, but the conditions have to be perfect; otherwise, 300+ ms between (simple) stimulus and (simple) response is more typical. Obviously, a lot of this is happening asynchronously, and high refresh rates can help in other ways (e.g., by smoothing out movement), but it astonishing how laggy our visual system is.
- rakoo 4y agoThose random input generators that take every move and feed it to the mixer. Not that they're actually useful.
- thfuran 4y agoOne tenth as fast as a virtual function call is incredibly fast.
- jerf 4y agoI like to bang on the drum that as a programmer, you need to understand the sheer number of orders of magnitude you're spanning more than the average programmer does. We so often deal in "10x slower" and "100x" slower that we can forget that it just doesn't matter if we're doing it even a mere 60 times a second. 10x slower on a process that takes 100ms is a problem. 10x slower on a process that takes 10ns requires a lot of looping to become a human-scale problem. There are things that can attain that level of looping, certainly, but it's not everything. A good programmer ought to have read that sentence and instinctively observed that between 100ms and 10ns is a full seven orders of magnitude. For two numbers that at the human level may seem not terribly far away from "zero", there's a lot of space between them.
- saidinesh5 4y agoI think onMouseMove is a QML/QtQuick specific thing. In C++/QWidgets I remember having to use mouseMoveEvent https://doc.qt.io/qt-5/qwidget.html#mouseMoveEvent https://doc.qt.io/qt-5/qwidget.html#mouseMoveEvent for that. As for download progress etc.. I don't think I have ever had to worry about speed of a function call ever - as long as I was leaving it to the event loop take care of it.
- tlb 4y agoonMouseMove is normally delivered at the video frame rate, 60 fps. The OP's benchmark shows it can deliver around 60M signals per second, so it uses about 1/1000000 of the CPU time. Seems tolerable.
- AlotOfReading 4y agoEven if it was delivered at the polling rate, that should never be higher than 1kHz (otherwise you deserve whatever performance issues you get). A virtual function call is 15ns conservatively, so say a signal is 150ns. 1000x is <150us of wasted time, well below observable overhead in any human-centric application.
- msbarnett 4y agoObjective-C was doing sufficiently-fast UI updates for it to run well on iPhones 10 years ago, while relying on objc_msgsend, which is _much_ slower than a virtual function call or even a Qt signal. You wouldn't want to use ObjC's message sending OR Qt's signalling mechanism in a tight inner loop – hell, you probably don't want to deal with the indirection of the vtable incurred by a virtual function in a tight inner loop. But all of these are more than fast enough for interactive UI work.
- eska 4y agoIn a tight loop you’d resolve the dispatch only once and call the resulting function repeatedly.
- morelisp 4y ago> objc_msgsend, which is _much_ slower than a virtual function call or even a Qt signal. objc_msgsend is slower than a virtual function, but like 1.1x-2x, not 10x. (In rare cases it can even be faster due to it being a little more predictor-friendly.) https://www.mikeash.com/pyblog/friday-qa-2016-04-15-performance-comparisons-of-common-operations-2016-edition.html https://www.mikeash.com/pyblog/friday-qa-2016-04-15-performa...
- ksherlock 4y agoAlso, 30 years ago, on NeXT hardware.
- cma 4y agoMemory latency hasn't improved that much since Next and these kind of virtual-like things cause lots of dependent reads.
- tinus_hn 4y agoObjc_msgsend on the other hand, has been optimized continuously. https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.html https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.h...
- nsonha 4y agonot that fast, it's still an user thing which is incredibly slow comparing to computation
- usefulcat 4y agoThe slowest number mentioned in the post--"32,562,683 signals [per second] with sender"--works out to about 31 nanoseconds. That's around half a dozen orders of magnitude less than an amount of latency that would be noticeable to a human.
- Gibbon1 4y agoThe little 50MHz Arm Cortex I'm using does one tick in 20 ns. Gate delay through old 74LSXX logic was like 10ns.
- slavik81 4y agoIn Qt, those sorts of input interactions are mostly handled through virtual function calls, not signals. You're basically referring to QWidget::mouseMoveEvent. https://doc.qt.io/qt-6/qwidget.html#mouseMoveEvent https://doc.qt.io/qt-6/qwidget.html#mouseMoveEvent
- jollybean 4y agoIf signals were only used for onMouseMove and such things, this wouldn't be big deal. It's when you start to have to use signals thousands of times per event that it becomes a problem. Signals for raw user events won't make a difference, but signals as the main mechanism of API interfacing is a problem. I would say it's a serious problem. I avoid using signals in general.
- sudosysgen 4y agoonMouseMove is going to be called at most like 3000 times a second, assuming a 240hz screen and the signal beinf sent through 12 objects. You're going to be using up, what, 300 microseconds? But even then, you're missing the point, because you don't have to use signals to detect the mouse moving if you don't want to.
- kaba0 4y ago10 times faster than a virtual call is still ridiculously fast on any general purpose CPU made in this century. We often forget how insanely fast they are (and at the same time, I have no idea how we manage to add as much bloat to certain stacks that they make the processor struggle). Like, I’m fairly sure you could have decent latency if your callback function for onMouseMove made a local network call to another process. Also, how fast do you think download progress should update? Animating it to the next keyframe every second is much more than enough.
- xbar 4y ago"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." Computers work faster than people who click manually.
- smiddereens 4y ago
- halter73 4y agoWhy would you use QT signals for that? The point is you do not have to interact with the UI at that high of a frequency.
- dekhn 4y agoThis really sounds like a naive implementation expecting that naive use of a feature is perfectly optimized. IE, don't use that number of signals, or treat signals like a broadcasting message bus. 10X the cost of a virtual function call is pretty optimized, btw.
- skrebbel 4y agoI strongly doubt the signals, even at 10x a virtual function call, are a bottleneck when handling 100k network requests in a second. When you're optimizing that deep, you can do that extra bit of work and replace the qt signal library by a real vtable. It's not what signals were designed for.
- davidw 4y agoI wrote Tcl/Tk code in the 90ies that was perfectly adequate in terms of user interaction, and that is a scripting language...
- morelisp 4y agoI haven't used Qt enough to speak meaningfully about its idioms but in GLib there's a signal for I/O ready on an fd (i.e. effectively a way to plug a select(2) into your UI event loop). I can easily imagine someone, accidentally or ignorantly, using this in a very stupid way.
- inferiorhuman 4y agoThe equivalent is QSocketNotifier (which uses select under the hood) and QFileSystemWatcher (which does complex stuff). It's been a long time since I've spent quality time with Qt but I don't remember anyone complaining about the performance of QSN.
- morelisp 4y agoSure, if you use it right it's not an issue. Not everyone uses everything right, and unlike e.g. mouse move or key press, this one could conceivably fire a million times a second if you use it wrong. Personally, I'm in the "I'm surprised it's only 10x" camp - I wonder who thought signals were fast to begin with?
- inferiorhuman 4y agoMe? The impression I had (granted it's been decades at this point) is that Qt/KDE apps were painfully slow to compile but were usually performant. Look at something like KHTML.
- kaba0 4y agoHow are 10 times a literal virtual call not performant? That’s 150 NANOsec.
- morelisp 4y agoIt sounds like you're not familiar with what signals are used for. I brought up the select(2) example because I wouldn't want to fire a signal for every byte (I probably wouldn't want to call a virtual function call, even). But for clicking the mouse, scrolling a page, kicking off a network request - you could go up to a full ms and you'd still feel that the app is (in a vague general sense) "performant".