[Mono-dev] File LastModified

2007-04-04 Thread José Alexandre Antunes Faria
Hi there guys,

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 (1 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.

Thanks,

SpigaZ out.


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

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] Monodoc

2006-01-03 Thread José Alexandre Antunes Faria
Hi there guys,

1) Is there a way to extend monodoc without changing the monodoc.xml
file?

I wanted to add documentation but without having to change it.

2) Is there a way to create nodes inside my documentation or only on the
monodoc.xml file?

Cheers,

SpigaZ out...


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] AppDomain major problem

2005-11-18 Thread José Alexandre Antunes Faria
Hi there guys,

Some of you were bothered by me on the IRC regarding a bug on AppDomain.

I was trying to create a clean AppDomain, but mono for some reason
copies the assemblies in the current domain.

So I was getting my own executable assembly in my new AppDomain. After
ours of reading mostly all MS documentation that I could find regarding
AppDomains. I started to suspect that it was in fact a bug.

So I downloaded .Net 2.0 and it worked just fine...

This bug just costed me 5 hours, damm, I'm stupid... I should have
guessed... 

Because I have spent those 5 hours trying all possible ways to get
around it, and the only way I can think of is by overriding the assembly
resolving mechanism.

Does any of you have some kind of clue of how I can get around it? Only
till someone finds time to fix it. I tried to spot the bug, but I was
brave enough to go deeper into the vm.

Yes, before you shoot me:
http://bugzilla.ximian.com/show_bug.cgi?id=76757

I just hope, this isn't another scary bug, like the one I found for
Baulig. (Baulig []s and good luck)

Cheers,

SpigaZ out...

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list