4 ms·

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)

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.

inferiorhuman 4y ago
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.
- morelisp 4y ago
  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?
  - inferiorhuman 4y ago
    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.
    - kaba0 4y ago
      How are 10 times a literal virtual call not performant? That’s 150 NANOsec.
    - morelisp 4y ago
      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".
      - inferiorhuman 4y ago
        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.
        morelisp 4y ago
        Context is key, I hope you feel better tomorrow.
        inferiorhuman 4y ago
        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 https://doc.qt.io/qt-5/qsocketnotifier.html
  - int_19h 4y ago
    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.)

inferiorhuman 4y ago

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.

morelisp 4y ago
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?
- inferiorhuman 4y ago
  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.
  - kaba0 4y ago
    How are 10 times a literal virtual call not performant? That’s 150 NANOsec.
  - morelisp 4y ago
    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".
    - inferiorhuman 4y ago
      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.
      - morelisp 4y ago
        Context is key, I hope you feel better tomorrow.
        inferiorhuman 4y ago
        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 https://doc.qt.io/qt-5/qsocketnotifier.html
- int_19h 4y ago
  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.)