[Interest] Scalability of QTimer or QObject::startTimer

Atlant Schmidt aschmidt at dekaresearch.com
Fri Oct 26 13:52:14 CEST 2012


> However, I intend to scale it to around 100,000 QTimers.

  I would *NEVER* take it on faith that any system would scale to support
  100,000 timers, let alone 100,000 timers emanating from one task. I would
  *DEFINITELY* test/benchmark this first.

  And I wouldn't be surprised to learn that a better approach would be to
  have a single timer firing at a fixed rate along with a series of "work lists"
  that contain the 100,000 things to be done at various times in the future.
  The exact approach to how to structure these "work lists" would depend
  on whether the timed events are one-shot or recurring.


From: interest-bounces+aschmidt=dekaresearch.com at qt-project.org [mailto:interest-bounces+aschmidt=dekaresearch.com at qt-project.org] On Behalf Of Bo Thorsen
Sent: Friday, October 26, 2012 6:45 AM
To: interest at qt-project.org
Subject: Re: [Interest] Scalability of QTimer or QObject::startTimer

Den 26-10-2012 11:18, Prashant skrev:

I intend to have quite a few QObject inherited classes each implementing a couple of timers. The resolution of these timers is expected to be around 1000ms. However, QTimer documentation states that
"If Qt is unable to deliver the requested number of timer clicks, it will silently discard some."
I don't know how to interpret this statement. Does it mean that if a timer has a very low resolution, some clicks are neglected. OR does it mean that if a significant number of clicks from various timers happens at around the same time, clicks will be discarded.
In my application, it is not so important to have the click delivered at the exact same time, it doesn't matter if clicks are off by x ms. However, if no clicks are delivered there is a problem. I intend to have around 2000 objects. However, I intend to scale it to around 100,000 QTimers.

It means if the thread is busy for so long that the timer should have fired X times, it may fire anything from 1 to X times. But it will at least fire once.

One note: If you have that many timers, Qt will have to do some tricks for you. It would normally use hardware timers, but I don't know of any system that offer 100.000 timers.

You might be better off implementing some sort of distribution object if that's possible.

Bo Thorsen.

Come by my DevDays talk in Berlin - "Designing for testability". Learn how to build and run your unit tests with the Qt application.

Fionia Software - Qt experts for hire.

Click here<https://www.mailcontrol.com/sr/w+jBakKtY2zGX2PQPOmvUoZ6CX!kCKjThiFTaBoJ9HAN5EGs7XpGcucQtJYhzEQCIWVm3D4qsuarbIY9K1KtKg==> to report this email as spam.

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121026/cd0250d6/attachment.html>

More information about the Interest mailing list