[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