8 ms·

"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"

"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..

tlb 4y ago
onMouseMove 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 ago
  Even 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.
thfuran 4y ago
One tenth as fast as a virtual function call is incredibly fast.
- jerf 4y ago
  I 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.
ehutch79 4y ago
What are you doing with onMouseMove that would be perceptible to the user at higher than 60fps, or even 120fps?
- rakoo 4y ago
  Those random input generators that take every move and feed it to the mixer. Not that they're actually useful.
- windows_sucks 4y ago
  nothing 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 ago
    I 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 ago
  Drawing perhaps?
  - jonhohle 4y ago
    Drawing 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.
saidinesh5 4y ago
I 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.
msbarnett 4y ago
Objective-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.
- ksherlock 4y ago
  Also, 30 years ago, on NeXT hardware.
  - cma 4y ago
    Memory latency hasn't improved that much since Next and these kind of virtual-like things cause lots of dependent reads.
    - tinus_hn 4y ago
      Objc_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...
- eska 4y ago
  In 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...
usefulcat 4y ago
The 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 ago
  The little 50MHz Arm Cortex I'm using does one tick in 20 ns. Gate delay through old 74LSXX logic was like 10ns.
slavik81 4y ago
In 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
nsonha 4y ago
not that fast, it's still an user thing which is incredibly slow comparing to computation
jollybean 4y ago
If 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 ago
onMouseMove 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 ago
10 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.

"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..

tlb 4y ago

onMouseMove 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 ago
Even 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.

thfuran 4y ago

One tenth as fast as a virtual function call is incredibly fast.

jerf 4y ago
I 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.

ehutch79 4y ago

What are you doing with onMouseMove that would be perceptible to the user at higher than 60fps, or even 120fps?

rakoo 4y ago
Those random input generators that take every move and feed it to the mixer. Not that they're actually useful.
windows_sucks 4y ago
nothing 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 ago
  I 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 ago
Drawing perhaps?
- jonhohle 4y ago
  Drawing 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.

saidinesh5 4y ago

I 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.

msbarnett 4y ago

Objective-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.

ksherlock 4y ago
Also, 30 years ago, on NeXT hardware.
- cma 4y ago
  Memory latency hasn't improved that much since Next and these kind of virtual-like things cause lots of dependent reads.
  - tinus_hn 4y ago
    Objc_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...
eska 4y ago
In 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...

usefulcat 4y ago

The 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 ago
The little 50MHz Arm Cortex I'm using does one tick in 20 ns. Gate delay through old 74LSXX logic was like 10ns.

slavik81 4y ago

In 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

nsonha 4y ago

not that fast, it's still an user thing which is incredibly slow comparing to computation

jollybean 4y ago

If 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 ago

onMouseMove 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 ago

10 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.