3 ms·
Sure, most Qt programs are UI based, which makes performance a sensitive issue. Even if you're running your UI on separate threads there's still a need for low-
by nicholassmith 14y ago
Sure, most Qt programs are UI based, which makes performance a sensitive issue. Even if you're running your UI on separate threads there's still a need for low-level aspects like strings to be as fast as possible. QString is used everywhere, the faster it is the smoother your application.
- rwmj 14y agoFor a program that will sit waiting for user interaction nearly 100% of the time, strings must be "as fast as possible"? That's leaving aside the small fact that they won't be as fast as possible because you're using ref-counting. My bigger point is that programming hasn't grown up yet. We're not an engineering discipline, using the best tools and making the highest quality things. We're stuck in this ridiculous world of shaving nanoseconds from string copies, at the cost of programmer time (which is vastly more expensive) and user dissatisfaction (when the programs crash).
- capisce 14y agoWell, with QML... http://en.wikipedia.org/wiki/QML http://en.wikipedia.org/wiki/QML Although, we've run into issues where the garbage collection in QML suddenly kicks in and causes skipped frames leading to jerky animations. Garbage collection is not a panacea, especially not if you want predictable performance, which a responsive and smoothly animating UI requires. There might be solutions like doing incremental time-bounded garbage collection or by not allowing garbage collection at all on the critical, has to run at screen refresh, animation path.