3 ms·

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

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

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