[Mono-bugs] [Bug 81346][Wis] New - GetLastWriteTimeUtc - Redudant Double Conversion from and to utc

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Tue Apr 10 15:16:43 EDT 2007


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by spigaz at gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=81346

--- shadow/81346	2007-04-10 15:16:43.000000000 -0400
+++ shadow/81346.tmp.10279	2007-04-10 15:16:43.000000000 -0400
@@ -0,0 +1,110 @@
+Bug#: 81346
+Product: Mono: Class Libraries
+Version: 1.0
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: CORLIB
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: spigaz at gmail.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: GetLastWriteTimeUtc - Redudant Double Conversion from and to utc
+
+One of my apps uses a great deal of files and check their lastmodified
+timestamps, as I guess many other do.
+
+When I was profiling it, I noticed that it was taking a great deal of
+time, getting the lastmodified attribute, so I gave it a look.
+
+And I found out that internally mono uses UTC time, meaning the libs
+always get the LastWriteTime in UTC. Then they convert it to LocalTime
+before any usage.
+
+Meaning that if the required is UTC, its converted back to UTC. That is
+two unnecessary conversions.
+
+I have run some tests (100000000 times getting the LastWriteTimeUtc),
+and have found out, that it wastes about 10% converting back to
+LocalTime. 
+
+I don't have a number on the conversion from utc to localtime, but I
+seen that you use some tricks on the DateTime.Now, so I would guess that
+it isn't that light either.
+
+I know that an optimization of 20% is close to nothing on things are are
+very little used, like file manipulation.
+
+I don't know if this was intentional ou its simply a mistake, as it in
+fact allows to simplify the implementation, but why isn't utc used
+instead of local?
+
+The same happens with the other GetLast*Time and SetLast*.
+
+I haven't proposed a patch, because I don't know it makes sense to fix
+this or not.
+
+I would appreciate your comment on this.
+
+I have tried many times to send this as an email to mono-list and
+mono-devel-list, but for some reason, I didn't got it, neither I got a
+response. Am I blacklisted?
+
+Thanks
+
+
+PS: Here are some snippets of the code in question.
+
+//// File.cs:
+
+
+public static DateTime GetLastWriteTime (string path)
+{
+ MonoIOStat stat;
+ MonoIOError error;
+ CheckPathExceptions (path);
+
+ if (!MonoIO.GetFileStat (path, out stat, out error)) {
+#if NET_2_0
+  if (error == MonoIOError.ERROR_PATH_NOT_FOUND || error ==
+MonoIOError.ERROR_FILE_NOT_FOUND)
+   return _defaultLocalFileTime;
+  else
+   throw new IOException (path);
+#else
+  throw new IOException (path);
+#endif
+ }
+ return DateTime.FromFileTime (stat.LastWriteTime);
+}
+
+public static DateTime GetLastWriteTimeUtc (string path)
+{
+ return GetLastWriteTime (path).ToUniversalTime ();
+}
+
+
+// DateTime.cs
+  
+public static DateTime FromFileTime (long fileTime) 
+{
+ if (fileTime < 0)
+  throw new ArgumentOutOfRangeException ("fileTime", "< 0");
+
+ return new DateTime (w32file_epoch + fileTime).ToLocalTime ();
+}
+
+#if NET_1_1
+public static DateTime FromFileTimeUtc (long fileTime) 
+{
+ if (fileTime < 0)
+  throw new ArgumentOutOfRangeException ("fileTime", "< 0");
+
+ return new DateTime (w32file_epoch + fileTime);
+}
+#endif


More information about the mono-bugs mailing list