Board index » cppbuilder » DateTime im miliseconds

DateTime im miliseconds


2005-04-14 05:07:44 PM
cppbuilder101
Hi
Anybody knows how can i measure time between 2 process..
my code is;
for(int i=0;i<100;i++)
{
TDateTime d1=Now();
DoJob();
TDateTime d2=Now();
}
So HOw can i get the time "in miliseconds" between d1 and d2?
 
 

Re:DateTime im miliseconds

mehmed sipahi wrote:
Quote
Anybody knows how can i measure time between 2 process..
int starttickcount = GetTickCount();
Quote
DoJob();
int endtickcount = GetTickCount();
int elapsedtime = endtickcount - starttickcount;
// in ms.
Hans.
 

Re:DateTime im miliseconds

"Hans Galema" < XXXX@XXXXX.COM >wrote in message
Quote
int elapsedtime = endtickcount - starttickcount;
First off, you are using signed variables when you should be using unsigned
ones. Your precision will be way off if you use signed values.
Second, you are not taking into account that the second call to
GetTickCount() can return a value that is less than the first value, which
happens when Windows' internal counter wraps back to 0 every 49.7 days. If
you don't take the wrapping into account, your elapsed value can never
handle the full 49.7 days. Not that you should have a process that runsfor
49.7 days straight, but the wrapping is still important in case the process
is started towards the end of the 49.7 days and the wrapping occurs while
the process is still running.
Gambit
 

{smallsort}

Re:DateTime im miliseconds

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
Second, you are not taking into account that the second call to
GetTickCount() can return a value that is less than the first value,
which happens when Windows' internal counter wraps back to
0 every 49.7 days.
With that said, use this instead:
DWORD start = ::GetTickCount();
//...
DWORD end = ::GetTickCount();
DWORD elapsed;
if( end>= start )
elapsed = (end - start);
else
elapsed = ((0xFFFFFFFF - start) + end);
Even better would be to use a high-performance counter via
QueryPerformanceCounter() and QueryPerformanceFrequency() instead, but I'll
leave that as a separate exercise for you to work out.
Gambit
 

Re:DateTime im miliseconds

Remy Lebeau (TeamB) wrote:
Quote
Second, you are not taking into account that the second call to
GetTickCount() can return a value that is less than the first value, which
happens when Windows' internal counter wraps back to 0 every 49.7 days.
Come on Remy. If mehmed wants to measure time in milliseconds then for sure
he will not have an elapsed time in the order of days. Look he even uses
this in a for loop 100 times.
Of course what you say is true. But it makes no sence with this problem.
Then a good hint maybe was using a QueryPerformanceCounter().
Hans.
 

Re:DateTime im miliseconds

"Hans Galema" < XXXX@XXXXX.COM >wrote in message
Quote
Come on Remy. If mehmed wants to measure time in milliseconds
then for sure he will not have an elapsed time in the order of days.
Please go back and re-read the second half of my earlier description. I
covered the situation where wrapping can still occur regardless of how long
the elapsed time actually is.
Quote
it makes no sence with this problem.
Yes, it does. It is a very valid condition that should be taken into
consideration *anytime* GetTickCount() is used. It applies whenever the
elapsed time is greater than 0 milliseconds, as wrapping can occur any time
after 0 milliseconds.
The 49.7 day limitation is due to GetTickCount() using a DWORD for the
milliseconds. The maximum value that a DWORD can hold is 0xFFFFFFFF, aka
4294967295 ms:
(4294967295 / 86400000) = 47.9 days
86400000 is the number of milliseconds in 1 day
Now, lets say that the machine has been running for almost 49.7 days. The
first call to GetTickCount() returns a value close to 0xFFFFFFFF. For sake
of discussion, let's say it returns 0xFFFFEC77, aka 5000ms (0x00001388) less
than the maximum that GetTickCount() can return.
Now, lets say that the operation being tracked runs for exactly 10 seconds.
(0xFFFFEC77 + 0x00001388) is 0xFFFFFFFF, the maximum that GetTickCount() can
count to. But the operation is only halfway finished, so GetTickCount() has
to reset to 0 and start over. Thus the next call to GetTickCount() returns
a value of 0x1388 for the remaining time. Wrapping just occured, even
though only 10 seconds elapsed. Using the algorithm of (end - start), which
does not take wrapping into account, will yield a wrong value:
(0x00001388 - 0xFFFFEC77) = 0x2711, aka -4294957295 ms
The correct value in this situation should be using the algorithm of
((0xFFFFFFFF - start) + end):
((0xFFFFFFFF - 0xFFFFEC77) + 0x00001388) = 0x2710, aka 10000 ms
Gambit
 

Re:DateTime im miliseconds

Remy Lebeau (TeamB) wrote:
Quote
The 49.7 day limitation is due to GetTickCount() using a DWORD for the
milliseconds.
Indeed. I know that.
Quote
Now, lets say that the machine has been running for almost 49.7 days.
Yee.. In that case yes. You are right. I oversaw that.
So one out of the hundred measurements done in that loop
could be inaccurate. I would not care. I think mehmed does not either.
Hans.
 

Re:DateTime im miliseconds

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
(0x00001388 - 0xFFFFEC77) = 0x2711, aka -4294957295 ms
When treated as decimals, this statement makes more sense:
(5000 - 4294962295) = -4294957295
Negative values are processed in 2s complement format, so -4294957295 is
00100111 00010001 in binary, which is 0x2711 in hex.
Quote
((0xFFFFFFFF - 0xFFFFEC77) + 0x00001388) = 0x2710, aka 10000 ms
In decimal, this statement is as follows:
((4294967295 - 4294962295) + 5000) = 10000
Non-negative values are not processed in 2s complement format, so 10000 is
binary 00100111 00010000, which is 0x2710 in hex
Gambit
 

Re:DateTime im miliseconds

"Hans Galema" < XXXX@XXXXX.COM >wrote in message
Quote
So one out of the hundred measurements done in that loop
could be inaccurate. I would not care. I think mehmed does
not either.
I think he would care if he started seeing grossly inaccurate elapsed times
like -4294957295 ms being reported.
Gambit