Inside CLR ngen.exe tool

The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead using the just-in-time (JIT) compiler to compile the original assembly.

The NGen.exe tool that ships with the .NET Framework can be used to compile IL code to native code when an application is installed on a user’s machine. Since the code is compiled at install time, the CLR’s JIT compiler does not have to compile the IL code at run time, and this can improve the application’s performance. The NGen.exe tool is interesting in two scenarios:

Improving an application’s startup time
Running NGen.exe can improve startup time because the code will already be compiled into native code so that compilation doesn’t have to occur at run time.

Reducing an application’s working set
If you believe that an assembly will be loaded into multiple processes/AppDomains simultaneously, running NGen.exe on that assembly can reduce the applications’ working set. The reason is because the NGen.exe tool compiles the IL to native code and saves the output in a separate file. This file can be memory-mapped into multiple process address spaces simultaneously, allowing the code to be shared; not every process/AppDomain needs its own copy of the code.

Now, whenever the CLR loads an assembly file, the CLR looks to see if a corresponding NGen’d native file exists. If a native file cannot be found, the CLR JIT compiles the IL code as usual. However, if a corresponding native file does exist, the CLR will use the compiled code contained in the native file, and the file’s methods will not have to be compiled at run time. On the surface, this sounds great! It sounds as if you get all of the benefits of managed code (garbage collection, verification, type safety, and so on) without all of the performance problems of managed code (JIT compilation). However, the reality of the situation is not as rosy as it would first seem.

There are several potential problems with respect to NGen’d files:

  1. No Intellectual Property Protection Many people believe that it might be possible to ship NGen’d files without shipping the files containing the original IL code thereby keeping their intellectual property a secret. Unfortunately, this is not possible
  2. NGen’d files can get out of sync :When the CLR loads an NGen’d file, it compares a number of characteristics about the previously compiled code and the current execution environment. If any of the characteristics don’t match, the NGen’d file cannot be used, and the normal JIT compiler process is used instead.
  3. Inferior Load-Time Performance (Rebasing/Binding) :
    Assembly files are standard Windows PE files, and, as such, each contains a preferred base address. Many Windows developers are familiar with the issues surrounding base addresses and rebasing
  4. Inferior Execution-Time Performance :
    When compiling code, NGen can’t make as many assumptions about the execution environment as the JIT compiler can. This causes NGen.exe to produce inferior code. For example, NGen won’t optimize the use of
    certain CPU instructions; it adds indirections for static field access because the actual address of the static fields isn’t known until run time. NGen inserts code to call class constructors everywhere because it doesn’t know the order in which the code will execute and if a class constructor has already been called.

 Ngen.exe has changed significantly in the .NET Framework version 2.0:

1) Installing an assembly also installs its dependencies, simplifying the syntax of Ngen.exe.
2) Native images can now be shared across application domains
3) A new action, update, re-creates images that have been invalidated.
4) Actions can be deferred for execution by a service that uses idle time on the computer to generate and install images.
5) Some causes of image invalidation have been eliminated.

 
Usage: ngen <action> [args] [/nologo] [/silent] [/verbose]
       ngen /? or /help
    /nologo    - Prevents displaying of logo
    /silent    - Prevents displaying of success messages
    /verbose   - Displays verbose output for debugging
Actions:
    ngen install <assembly name> [scenarios] [config] [/queue[:[1|2|3]]
        Generate native images for an assembly and its dependencies
        and install them in the Native Images Cache
        If /queue is specified compilation job is queued up.  If a priority
        is not specified, the default priority used is 3.
    ngen uninstall <assembly name> [scenarios] [config]
        Delete the native images of an assembly and its dependencies from
        the Native Images Cache.
    ngen update [/queue]
        Update native images that have become invalid
        If /queue is specified compilation jobs are queued up.
    ngen display [assembly name]
        Display the ngen state
    ngen executeQueuedItems [1|2|3]
        Executes queued compilation jobs.
        If priority is not specified all queued compilation jobs are done.
        If priority is specified compilation jobs with greater or equal.
        priority than the specified are done.
    ngen queue [pause|continue|status]
        Allows the user to pause and continue the NGen Service, and to
        query its status.
Scenarios:
    /Debug          - Generate images that can be used under a debugger
    /Profile        - Generate images that can be used under a profiler
    /NoDependencies - Generate the minimal number of native images
                      required by this scenario
Config:
    /ExeConfig:<path to exe> - Use the configuration of the specified
                 executable assembly
    /AppBase:<path to appbase directory> - Use the specified directory as
                 the appbase

Sources :
MS Press ,CLR via C# 2th Edition , Jeffrey Richter
http://msdn.microsoft.com/en-us/library/6t9t5wcf(VS.80).aspx

Knowledge is power !

NameObjectCollectionBase Sample c#

this is a  special collection in  System.Collections.Specialized . Main speaciality that it allows duplication keys to be added to the hashtable. It provides the abstract base class for a collection of associated String keys and Object values that can be accessed either with the key or with the index.

An Example:

 public sealed class ExecutionModuleCollection : NameObjectCollectionBase
    {
        private readonly object syncRoot = new object();
 
        public object SyncRoot
        {
            get { return this.syncRoot; }
        }
 
        public string[] AllKeys {
            get
            {
                return this.BaseGetAllKeys();
            }
        }
 
 
        public IExecutionModule this[int index]
        {
            get
            {
                return (IExecutionModule) this.BaseGet(index);
            }
            internal set
            {
                this.BaseSet(index, value);
            }
        }
 
        public IExecutionModule this[string name] {
            get
            {
                return (IExecutionModule) base.BaseGet(name);      
            }
            internal set
            {
                base.BaseSet(name, value);
            }
        }
 
 
        public void CopyTo(Array dest, int index)
        {
            Array.Copy(base.BaseGetAllValues(), dest, index);
        }
 
        public IExecutionModule Get(string name)
        {
            return (IExecutionModule)base.BaseGet(name);
        }
 
        public string GetKey(int index)
        {
            return  this.Keys[index].ToString() ;
        }
 
        public void Add(ExecutionModule module)
        {
            base.BaseAdd(module.Name, module);
        }
    }

Attention:

You can not insert value in specific order because it uses a hashtable in background and this kind of insertation break it.If you need it to be ordered, you should  use  an OrderedDictionary or SortedDictionary<T,T>.

About Thread Safety

Public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

Enumerating through a collection is intrinsically not a thread safe procedure. Even when a collection is synchronized, other threads can still modify the collection, which causes the enumerator to throw an exception. To guarantee thread safety during enumeration, you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.

SyncRoot , lock(this) and Syncronized Pattern

You have an object and you want to use one of function that object as threadsafe you can use lock(object) statement for syncronization. But it can cause a deadlock if you are using “lock(this) ” . it occurs when derived classes want to try lock before your inner function execute and also it never gonna execute , because of your inner function wating first lock to be removed but it never be done here is the DeadLock!!  .

    public class MyClass
    {
        public void DoSomething()
        {
//DO NOT USE locking like this
            lock (this)
            {
               
            }
        }
    }

Dead Lock Example:

        MyClass cs = new MyClass();
        public void ThreadWorker() //this function is called by another thread
        {
            lock (cs) // DEADLOCK !!!
            {
                cs.DoSomething();
            }
        }

Here is the golden rule :

 If you have an internal data structure that you want to prevent simultaneous access to by multiple threads, you should always make sure the object you’re locking on is not public.

The reasoning behind this is that a public object can be locked by anyone, and thus you can create deadlocks because you’re not in total control of the locking pattern.
This means that locking on this is not an option, since anyone can lock on that object. Likewise, you should not lock on something you expose to the outside world.
Which means that the best solution is to use an internal object, and thus the tip is to just use Object.
Locking data structures is something you really need to have full control over, otherwise you risk setting up a scenario for deadlocking, which can be very problematic to handle.

Example

 public class MyClass
    {
// Use an inner object for locking.
        object _SyncRoot = new object();
        public void DoSomething()
        {
            lock (_SyncRoot)
            {
                int val = DateTime.Now.Second;
                Console.WriteLine("1) Do Someting Called by " + Thread.CurrentThread.Name);
                while (val - 1 != DateTime.Now.Second)
                {
                    //do some thing 
                }
                Console.WriteLine("1) out");
            }
        }
    }

Most of syncronization tasks  be used when working on collections  and Syncronized Pattern and  ICollection.SyncRoot Property is already exists for c# collections you dont need to create your own.
But if you have a custom object you can use  Syncronized Pattern for your classes . There is an example of Thread Safe wrapper code:

    class MyClass
    {
        private class SynchronizedClass : MyClass
        {
            private object syncRoot = new object();
            private MyClass _instance;
            public SynchronizedClass(MyClass cls) { _instance = cls; }
            public override bool IsSynchronized { get { return true; } }
            public override void Funk1() { lock (syncRoot) { _instance.Funk1(); } }
            public override void Funk2() { lock (syncRoot) { _instance.Funk2(); } }
        }
        public virtual bool IsSynchronized { get { return false; } }
        public static MyClass Synchronized(MyClass cls)
        {
            if (!cls.IsSynchronized)
                return new SynchronizedClass(cls);
            return cls;
        }
        public virtual void Funk1() { /* Your code here */ }
        public virtual void Funk2() { /* Your code here */ }
    }
See:
http://msdn.microsoft.com/en-us/library/system.collections.icollection.syncroot.aspx
http://stackoverflow.com/questions/728896/whats-the-use-of-the-syncroot-pattern
Happy Codding !!!

XmlSerializer Memory Leak Solution

This problem occurs because an assembly that contains Microsoft intermediate language (MSIL) is created and loaded into memory when you create an XmlSerializer object. You cannot unload the assembly without unloading the application domain that it resides in. Therefore, when you create several XmlSerializer objects, you may notice unexpectedly high memory usage.

For example, if you use the following constructor to create several XmlSerializer objects, a new temporary assembly is created every time:

public void XmlSerializer( Type t, Type[] extraTypes)

To work around this problem of re-creating assemblies, use one of the following methods:
Create one instance of the XmlSerializer class, and put that instance in the cache by using the caching APIs. For example, for a .dll file that is named HighSchool, the following code caches one instance of the XmlSerializer class:
XmlSerializer mySerializer = new XmlSerializer(typeof(HighSchool.MyClass), attrOverrides, extraTypes, root, “http://www.microsoft.com“);
Cache[“HighSchoolSerializer”] = mySerializer

  • Use the instance of the XmlSerializer class that you put in the cache instead of creating a new XmlSerializer object every time.
  • Use the following XmlSerializer class constructors. These class constructors cache the assemblies:
    In the .NET Framework version 1.0
     public XmlSerializer(Type);
    In the .NET Framework version 1.1
    public XmlSerializer(Type type);
    public XmlSerializer(Type type, string defaultNamespace);
  • Declare the XmlSerializer object to be a static member of a class.

Source:
http://support.microsoft.com/kb/886385

Chain ?? operator

You can chain more than one nullable variable and if all null it return string.Empty

string value = valx ?? valy?? valz ?? string.Empty;

Nice isnt it ?