[Mono-dev] Cosmetic / Performance: Getting LastModifiedUtc causes unnecessary convertion

José Alexandre Antunes Faria spigaz at gmail.com
Sun Feb 11 09:31:52 EST 2007


Hi there,

I just found out that to get the LastModifiedUtc from a file, it does a
convertion to LocalTime and then a conversion to UniversalTime.

I made a very heavy usage test case, and found out that 10% of the time
it takes to get me the LastModifiedUtc from a File is from the
ToUniversalTime() (I tested vs the LastModied). As this one  is just
equal to LastModifiedUtc without the ToUniversalTime.

So that means that the LastModifiedUtc, 20% of its execution time if it
doesn't do both unnecessary conversions, assuming that ToLocalTime takes
about the same time as ToUniversalTime.

But I understand, that there might be a catch, a reason why this was
done this way.

So I'm asking here do you guys know why this is like this?

Should I file this as a bug on bugzilla?

Thanks,
SpigaZ out...


PS: Here is the detail:


To get the LastModifiedUtc, you can use File.GetLastWriteTimeUtc:

public static DateTime GetLastWriteTimeUtc (string path)
{
  return GetLastWriteTime (path).ToUniversalTime ();
}

Wich in turn uses:
DateTime.FromFileTime (stat.LastWriteTime);

That does:
return new DateTime (w32file_epoch + fileTime).ToLocalTime ();

i don't know if this was done like this on purpose, perhaps some side
effect of ToLocalTime?

This is just something that may hurt a bit the performance of file
intensive applications where the LastModified of a file is relevant.





More information about the Mono-devel-list mailing list