7 ms·

For twenty years no Qt developer has complained about the speed of Qt signals. Even in PyQt the speed of Qt signals is not issue - it's the code responding to t

• antoineMoPa 4y ago
  > anyone who is worried about it is having a severe case of premature optimization. I think the "This is a premature optimization" mindset is what leads to slow pieces of software that I like to avoid (React, Qt, electron). But I guess it's fine, as most users don't care as much as I do.
  • Sakos 4y ago
    Qt is slow now? All the Qt-based applications I've used are as fast as anything else can be.
    • simonh 4y ago
      From context it seems poster may believe Qt is some form of web framework, or something.
      • antoineMoPa 4y ago
        Not sure why you believe that, I built some (small) Qt applications so I know it's not a web framework, I was just referring to slow software in general. I think it's less true now, but I remember KDE (Qt-based) being slower and buggier than gnome (Gtk-based) a couple of years ago, just to cite one thing. It just felt like Qt-based stuff was in general more of a pain to use & heavier than GTK based stuff. It's really a matter of personal preference here and Qt is a nice project, just that I have some criticism here regarding performance choices. I feel like bad performance decisions tend to snowball and get multiplied when people make library choices and add their own performance issues on top.
        • simonh 4y ago
          > Not sure why you believe that… Because you included it in a list that otherwise only contained web tech frameworks. It’s not clear to me why you think those are peers of Qt and implied to me that you think they are near equivalents.
        • int_19h 4y ago
          KDE apps tend to use KDE frameworks, which is quite a bit of stuff on top of what pure Qt offers. Pure Qt apps were always comparable to Gtk in performance.
        • kaba0 4y ago
          With all due respect, you made quite a strong claim based on very little proof/experience.
          • antoineMoPa 4y ago
            Yeah I agree, I don't have actual data to back this snowballing effect idea.
    • criddell 4y ago
      AFAIK, Autodesk Fusion 360 is a Qt app and it's very slow compared to similar tools (like SolidWorks).
      • cuteboy19 4y ago
        The actual processing is slow, not the UI
      • inferiorhuman 4y ago
        Fusion is slow in large part because it makes a ton of HTTP requests. The Qt part is fairly performant.
      • jrockway 4y ago
        Fusion 360 is kind of a mess that's gotten way out of control. I enjoy how the navigation cube can literally draw outside the boundaries of the window as you move the window around. I don't think that's a Qt problem, I think they glued ten different UI libraries together to keep their legacy code working.
        • inferiorhuman 4y ago
          Fusion is probably the newest software product that Autodesk rents. In fact it was Carl Bass' passion project. Unfortunately Autodesk's software development process is… broken.
      • ravenstine 4y ago
        The fact that it's made by Autodesk is probably the reason that it's slow, not because it uses Qt. Various Autodesk products have been clunky, buggy, crashy, slow pieces of crap (I'm looking at you, Maya) since before they were migrated to Qt.
      • dekhn 4y ago
        The UI is totally performant for me. The only time it's bogged down was when I was modelling something with > 100k mesh triangles. Or when I do a long UI-blocking processing operation (which isn't in the qt codepath)./
    • Kaze404 4y ago
      Everything is slow when the goal is to just complain about things you don't understand.
  • spaetzleesser 4y ago
    Comparing Qt overhead to the insane overhead of JavaScript frameworks is a little far fetched.
    • ajuc 4y ago
      Qt has QML which is a js framework :)
      • JustSomeNobody 4y ago
        Optional isn't it?
      • Kelteseth 4y ago
        You can call js functions in qml, but that does not mean qml is a js framework. Normally you call your c++ functions from qml.
        • ajuc 4y ago
          I don't want to disparage qt+qml, I used it commercially and it's much better than other gui frameworks I worked with. I just dislike people bashing technology for the wrong reason (like it being a "js framework"). In qt+qml usually you connect slots to signals in js, even if they are implemented in c++.
    • chrisseaton 4y ago
      A function call in JS is usually just a few machine instructions. It's an example of a case where a conventional C++ compiler can do less optimisation than a JIT JS compiler.
      • int_19h 4y ago
        I would find it extremely surprising if a regular function call in C++ took any more instructions than in JS. Now a virtual function call, a JIT compiler can devirtualize more often than an AOT compiler. But the vast majority of function calls in your typical C++ app are not virtual.
  • dec0dedab0de 4y ago
    I think you're thinking of the "any optimization will be too diffcult, take too long, and cost too much" mindset. Which is a huge problem. Being mindful enough to identify when you're feeling the urge to optimize something too soon, will let you step back and optimize what will have the biggest impact once it's finished. I have seen developers spend hours optimizing some functionality, pick the fastest technique, and it turned out by designing everything to work with their earlier optimizations they made the overall system much slower.
  • sudosysgen 4y ago
    How is Qt slow? Do you have benchmarks of Qt vs JavaFX, UWP, SwiftUI or Electron showing that it's slow, let alone comparable to Electron or React? 10x the latency of a virtual function call for a signal is very very small beans compared to where you're actually spending CPU cycles, for any reasonable software.
    • antoineMoPa 4y ago
      Qt is heavyweight when compared to say Gtk. But that being said, I agree that Qt perf is much better than electron / JavaFX. I mean everything is a tradeoff. Gtk Is more complex to develop-with than Qt, electron super easy, but super memory intensive. My main point is that we should not always think "This is premature optimization". This mindset makes it very difficult to care about performance in modern organizations.
      • sudosysgen 4y ago
        Qt is generally as fast as GTK. It's a bigger library that does a lot more but it is still as fast or faster. I agree that we shouldn't always think "this is premature optimization". However, we should focus our optimization efforts where they matter, and I really struggle to think of a place where signal latency is really crucial. In any well architected software that's going to be really rare and it makes sense to focus your efforts on optimizing other parts of the software, which seems to be what the Qt devs did.
• saidinesh5 4y ago
  This post did raise an interesting question for me though. With Qt being used on microcontrollers these days, It made me wonder about the overhead of signals and slots on single core/single threaded usecases and how that might affect things like power consumption/CPU usage on those devices. I would love to see if someone did a comparison on that. As for the crazy contrived example they have provided: "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." - They'd have to process the incoming messages on a separate thread (or process) anyway, so they wont drop packets because of the event loop that also processes user input. Then update the GUI once every event loop tick because that's how frequently the UI gets updated anyway.
  • Tao3300 4y ago
    The more slowly you can interact with a "crypo exchange" the better, right?
    • saidinesh5 4y ago
      Hahah touche.
  • Bigpet 4y ago
    > With Qt being used on microcontrollers these days Is it really though? It's used in embedded systems. I wouldn't call those that can run Qt UIs microcontrollers.
    • saidinesh5 4y ago
      Well they did show it off a lot recently. STM32F7 and STM23H7s. Not sure how many "real companies" use it though. https://www.qt.io/microcontrollers-st https://www.qt.io/microcontrollers-st . As per my old boss, the difference in prices when it comes to these microcontrollers and "less powerful" linux socs is negligible that it wasn't worth trying to target them. Not sure if/how the economics changed over the last 2-3 years either.
• deleted 4y ago
  [deleted]
• devwastaken 4y ago
  null erasure. You can't know a negative existence. You know what I do when I encounter things that don't work the way I want? I don't go to qt forums and complain, because nothing happens. I code something else and move on. The issue is still there.
• jbluepolarbear 4y ago
  I used Qt quite extensively about 10 years ago and we constantly complained about signals. Was working in real-time medical simulations and interfacing with the many io devices we had was painfully slow. Also (at the time) keeping an OpenGL frame (we had multiple at a time) required signal communication that was a high overhead. We ended up replacing all of the signal beside setting up and tearing down the application and handling of system events. Signals are a bad design and I’ll stand on that hill forever.
  • TillE 4y ago
    There are many many things you should never use if you need ultra low latency and/or ultra high bandwidth. That doesn't make them badly designed, simply not suitable for every purpose. Qt signals are absolutely fine for like 99% of their usage.
    • jbluepolarbear 4y ago
      Absolutely not, signals and slots make a spaghetti mess of messaging. Often causing a many to one to many dependency hell. In simple cases signals and slots work fine, but quickly become overwhelming as the project grows. I’ve not worked in any large Qt project that wasn’t a dependency mess and a chore to do anything. Signals and slots are a crutch of poor design.
• jokoon 4y ago
  premature optimization has become a meme at this point
• usefulcat 4y ago
  > the speed of Qt signals is not issue - it's the code responding to the signal that can be a problem. Even if the callback were infinitely fast, if it's called 10e6 times per second, the work already can't take longer than 100 ns on average (10e6 * 100ns = 1e9ns = 1 second). So a more useful way to frame this would be in terms of the ratio of the callback overhead to the work done by the callback (both measured in time), but there's no mention of the latter. In this particular case, this is a pretty obvious case of 'this is the wrong tool for the job', at least with the stated requirements. Also, at the point where you need to do something 10e6 times per second it's usually appropriate to think about how you might distribute that work across multiple cores.
• tinus_hn 4y ago
  Alternatively people avoid using the feature because it is too slow, so it appears not to matter.