Performance System.DateTime.Now

Hello

The API function
GetSystemTime(out st);
(PInvoke) is about 1500 faster then
System.DateTime.Now;

System: WinCE50 on ARMV4I

TestCode:

using System;
using System.Data;
using System.Runtime.InteropServices;

namespace DateTimePerformance
{
public struct SystemTime {
public ushort wYear;
public ushort wMonth;
public ushort wDayOfWeek;
public ushort wDay;
public ushort wHour;
public ushort wMinute;
public ushort wSecond;
public ushort wMilliseconds;
}

/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
[DllImport("coredll.dll")]
public static extern void GetSystemTime(out SystemTime st);

/// <summary>
/// The main entry point for the application.
/// </summary>
static void Main(string[] args)
{
int startTime;

Console.WriteLine("Hello World");
Console.WriteLine("");

for (int i = 0; i < 3; i++) {
startTime = System.Environment.TickCount;
readDateTime();
Console.WriteLine("Time: {0}", System.Environment.TickCount - startTime);
}

for (int i = 0; i < 3; i++) {
startTime = System.Environment.TickCount;
readDateTimeApi();
Console.WriteLine("Time: {0}", System.Environment.TickCount - startTime);
}

Console.WriteLine("");
Console.WriteLine("press any key to continue");
Console.ReadLine();
}

static void readDateTime() {

System.DateTime buf;

for (int i = 0; i < 10000; i++) {
buf = System.DateTime.Now;
if (buf.Hour == 1) {
Console.WriteLine("prevend compiler optimation");
}
}
}

static void readDateTimeApi() {

SystemTime st = new SystemTime();

for (int i = 0; i < 10000; i++) {
GetSystemTime(out st);
if (st.wHour == 1) {
Console.WriteLine("prevend compiler optimation");
}
}
}
}
}

Is there an explanation We need this function for logging.

Thank you very much

Answer this question

Performance System.DateTime.Now

Dycker
Intresting...
Anmol Ranka
Sorry, happymozart, what is solved

Tryst
ShAdeVampirE
Exactly! Also the API-Function GetTimeZoneInformation is now faster.
Mark Goldstein
with the registry key the performance is now acceptable
pu132
When we enter a key "TimeZoneInformation" under "HKEY_LOCAL_MACHINE\Time" our problems are solved.

thx
TomJ72
Thank you very much
siavoshkc

While I can't answer you question about the delay I can tell you to use a high performance counter when performing metrics. Try this post:

http://msdn.microsoft.com/library/default.asp url=/library/en-us/dncfhowto/html/uperfcoun.asp
Sarah71

Generally, using QueryPerformanceCounter is the more precise solution. This varies by hardware support, where it may just end up defaulting to GetTickCount. You can call QueryPerformanceFrequency to get the resolution.

The results you are getting using QueryPerformanceCounter are very, very strange. DateTime.Now calls GetSystemTime and then does a bunch of calculations, so it should take longer than just PInvoking GetSystemTime. I tried my experiment with QueryPerformanceCounter instead of TickCount and got the same results, in terms of ratios between the times for each call.
Dennie-DeTi
There is an explanation, but it won't help you much. Internally, DateTime.Now starts with GetSystemTime, then converts it to FileTime, then converts FileTime to UTC DateTime, then uses current timezone to convert it back to local time. I'm sure internally there is (or wa) a reason for it, but for the moment if you want to get the current time really fast - keep PInvoking GetSystemTime.
aimeeoco
OK- I have run tests here on an MC50 PocketPC device (do these have the ARM platform ). I get the following when PInvoking to get the results

The following are from using the QueryPerformanceCounter() PInvoke calls

These are using the GetSystemTime() PInvoke...
3410
3511
3619

These are using the DateTime.Now.
3285
3295
3306

And the following are from using the System.Environment.TickCount calls.

These are using the GetSystemTime() PInvoke...
102
109
99

These are using the DateTime.Now.
3274
3261
3222

So which ones am I meant to follow If your saying that the performance counters are what we should follow, then there isn't much between DateTime.Now and GetSystemTime() PInvoke, is there

Tryst
141695

I ran your code on WinCE 5.0 x86 and Windows Mobile 5.0 ARMV4I. I got results of 100 and 20 times, respectively, for .Net CF v2.0, and 100 and 30 for .Net CF v1.0. The performance would seem to vary greatly by platform considering that you found a 1500 times difference on your system.

Yes, there is some necessary overhead in DateTime.Now and no, it wasn't meant to be called repeatedly. You could stick with PInvoking to GetSystemTime or you could use DateTime.UtcNow, which has comparable performance.
anomolous
so performance is now acceptable when using the DateTime.Now statement

Tryst
Performance System.DateTime.Now

Answer this question