Hacker News Reader

Comment by skrebbel | Hacker News Reader

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.

View on HN

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

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

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.

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

nothing but if you want to do something, say even at 1fps, you need to enable the signal to fire in the first place.

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

Drawing perhaps?

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.

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

Those random input generators that take every move and feed it to the mixer. Not that they're actually useful.

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

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.

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.

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.

In a tight loop you’d resolve the dispatch only once and call the resulting function repeatedly.

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

Also, 30 years ago, on NeXT hardware.

Memory latency hasn't improved that much since Next and these kind of virtual-like things cause lots of dependent reads.

Objc_msgsend on the other hand, has been optimized continuously.

https://www.mikeash.com/pyblog/objc_msgsends-new-prototype.h...

There's a chart of various timings here [1] and objc_msgSend is actually pretty efficient (it's received a lot of optimization over the years for obvious reasons).

A cached IMP is faster than a C++ virtual method call (both of which are slower than a non-virtual method call, inline code, or a C function call of course).

[1] https://www.mikeash.com/pyblog/performance-comparisons-of-co...

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.

The little 50MHz Arm Cortex I'm using does one tick in 20 ns. Gate delay through old 74LSXX logic was like 10ns.

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

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

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.

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.

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.

I wrote Tcl/Tk code in the 90ies that was perfectly adequate in terms of user interaction, and that is a scripting language...

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

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

Sure, 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?

Me? 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.

How are 10 times a literal virtual call not performant? That’s 150 NANOsec.

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

lolwut

Having written a few kioslaves decades ago, I feel pretty qualified to comment on Qt's signal/slot performance. Similar to select and poll, QSocketNotifier fires off a signal when there's data ready on an fd. Typically you won't see an event per byte with either interface (unless you're deliberately writing obtuse code).

I think that a lot of the "Qt is slow" nonsense came from C++'s awful reputation especially when it came to templates. The reality was that signals/slots were always a slick and performant wrapper around callbacks. It's worth noting that Qt in all its glory is available on QNX (a well known RTOS) and has been since 4.6. Performance is a non-issue.

Context is key, I hope you feel better tomorrow.

What context am I missing? You're talking about network I/O as being a bad use case for signals/slots and I've pointed out that I (along with other KDE folks) wrote code using signals/slots to handle incoming network data. That's what Trolltech recommended and almost certainly what the current crop of ioslaves do today (okay I lied, it looks like there are dedicated socket classes that provide their own signals these days). It's actually pretty difficult to structure something such that a signals/slots become a performance bottleneck.

Insofar as other overhead sensitive environments go, Trolltech ported Qt (including the signal/slot paradigm) to a realtime OS (QNX) and features it prominently in safety critical contexts (e.g. automotive dashboards).

   I wonder who thought signals were fast to begin with?

You're surprised signals are fairly low overhead (and that's fine) and and wondered if anyone actually thought they were performant. Having dabbled with Qt off and on for decades I wasn't surprised. The beauty of moc is that it front loads a lot of the magic. Compiling it sucks (less now), running it typically doesn't.

https://doc.qt.io/qt-5/qsocketnotifier.html

Semantically, a signal is basically just a collection of method pointers + receivers for the same, so one could reasonably expect the same performance as iterating over a bunch of function pointers and calling them in turn. Which shouldn't be 10x slower than calling a single pointer.

(I believe the reason why it doesn't quite work that way in practice is because slot dispatch is ID-based, not pointer-based.)

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

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

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

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

Wait until he finds out the display refreshes at most 240 times per second…

1000Hz polling on a mouse seems acceptable for gamers... (Google shows some mice supporting 8000Hz, but that seems like an overkill)

If you're using signals for anything that may reach "10.000.000 signals per second" then you're doing it wrong.

Sounds like the guy who wanted an event to be fired for each audio sample and required 44100 samples per second. Interestingly, qt signals maybe even fast enough for just that.

At some point you have to consider whether your way of doing things is at all sensible.

Signals are good for rare, unpredictable events. If you have a firehose worth of data coming in, you're not sitting around waiting very often. Your data probably also has some commonality to it, and can be handled in bulk. If you have 100K events coming in, they're probably events of the same type.

Just like if you're writing gigabytes to a file, a program written with the most minimum amount of intelligence isn't going to do it one character at a time.

Even if you are getting 100,000 events per second - your GUI only updates at 60fps or 120fps - so you'd want to batch those events and try to update the GUI only once every frame.

Also to process important incoming messages on the same thread as the main event loop - where other things like user input, application drawing is handled, is kind of a bad idea.

Reply on news.ycombinator.com