836883 - [Perf] Consider smarter TimeStamp arithmetic to potentially get better performance

Status: RESOLVED WONTFIX

(Core :: XPCOM, enhancement)

Description

[Honza Bambas (:mayhemer)]

Bug 827287 introduces TimeStamp::NowLoRes().  It is using fast GetTickCount() to determine "now".  It may have much better performance, but has much worse resolution.  It can be compared to TimeStamp::Now() safely, tho.

I was trying to modify our timer (TimerThread and nsTimerImpl) to use NowLoRes() when possible (for larger duration/delay values).  Not an easy task at all.

TimeStamp::Now() on windows works the way it stores both QueryPerformanceCounter AND GetTickCount values.  NowLowRes() only GetTickCount.

We always count TimeDuration as a result of two TimeStamp's difference, where usually one of them is Now() to have a meaningful value in hands to use for logic decisions.

I would like to have |bool TimeStamp::NowLessThen(TimeStamp& other)| and |TimeDuration TimeStamp::NowMinus(TimeStamp& other)| methods which would be smart enough to use TimeStamp::NowLoRes() when duration/difference between "now" and |other| is more then say 150ms.

This is just an idea, but since QPC is 100 times slower on some platforms then GTC, it might give some perf benefit, mainly in the timer where Now() is heavily used on the main thread.

Comment 1

[Nick Lowe]

Related to Windows XP and Server 2003 support, I have also submitted: https://bugzilla.mozilla.org/show_bug.cgi?id=1014111
(Firefox only uses 32-bits of the 64-bits that GetTickCount actually returns.

Comment 2

[Honza Bambas (:mayhemer)]

I no longer think this is a good idea to do.  We want the precise difference all the time.  When high precision is not needed, one can always compare to NoLowRes().