compiler optimization switch

There are two C# compiler switches that impact code optimization: /optimize and /debug.

On disabing optimize switch (/optimize-), the unoptimized IL code produced by the compiler contains many no-operation (NOP) instructions and also branches that jump to the next line of code. On debugging in IDE, the extra instructions make code easier to debug by allowing breakpoints to be set on control flow instructions. On enabling the switch (/optimize+), compiler will remove these NOP and branch instructions

On enabling debug switch (+/full/pdbonly), the compiler produces a Program Database (PDB) file which helps the debugger find local variables and map the IL instructions to source code. /debug:full switch tells the JIT compiler that you intend to debug the assembly, and the JIT compiler will track what native code came from each IL instruction. This allows you to use the just-in-time debugger feature of Visual Studio to connect a debugger to an already-running process and debug the code easily.

By default, Debug version has /optimize- and /debug:full switches. But Release configuration has /optimize+ and /debug:pdbonly switches specified.

Recently, one of my collegue KarthickAlagar generated the big impact in prod launch. Hats off for his Release mode analysis!

Contents of .NET Managed Module

There are 4 components in a .NET Managed Module. They are listed as:

1. PE32(Portable Executable 32 bit) or PE32+ header

2. CLR (Common Language Runtime) header

3. Metadata (Data about data)

4. IL(Intermediate Language) Code

PE file header is similar to the Common Object File Format (COFF) header. If the header uses the PE32 format, the file can run on a 32-bit or 64-bit version of Windows. If the header uses the PE32+ format, the file requires a 64-bit version of Windows to run. This header also indicates the type of file: GUI, CUI, or DLL, and contains a timestamp indicating when the file was built.

CLR header contains the version of the CLR required, the MethodDef metadata token of the managed module’s entry point Main method, and the location/size of the module’s metadata, resources, strong name, etc

Every managed module contains two types of metadata tables: tables that describe the types and members defined in your source code and tables that describe the types and members referenced by your source code.

During compilation, .NET source code is converted into the intermediate format to be known by CLR. This type of intermediate format code is termed as IL in .NET environment. At runtime, the CLR converts IL into native CPU instructions.

Compiler switch /Platform

On drilling one of C# compiler (CSC) switch /platform, learned quite interesting info. Letz share it here.

Platform has 4 key switches, anycpu(default), x86, x64 and Itanium. anycpu switch creates PE32/agnostic signature in managed module, which runs as 32 bit app in x86 Windows, as 64 bit in x64 Windows and 64 bit in IA64 Windows. Second switch x86 creates PE32/x86 sign in module, which runs as 32 bit in x86, WoW64 (Windows on Windows64) in x64 & IA64 Windows.

x64 switch creates PE32+/x64 in managed module, which runs as 64 bit app only in x64 Windows. Last switch Itanium makes PE32+/Itanium signature, which runs as 64 bit app only in IA64 Windows.

Windows OS loads x86, x64, or IA64 version of MSCorEE.dll into the process’s address space from C:\Windows\System32 directory. For WoW64, it loads from C:\Windows\SysWow64 directory. Primary thread calls a method defined inside MSCore.dll. This method initializes the CLR, loads the EXE assembly, and then calls its entry point method (Main). At this point, the managed application is up and running.

.NET FW 4.0 has Environment’s Is64BitOperatingSystem property to determine if it is running on a 64-bit version of Windows

Enum usage in WCF

On working in a defect tracking tool using WCF, I faced a weird problem and thought it might be interesting to you.

Application throws service connection error when I used enums in data contract. The real problem was: DefectStatus
enums was assigned with int values. Itz started by 1 instead of 0. Obviously WCF requires that there is an enum value equal to 0 for serialization. If not, server layer won't get that to your client through WCF - strange but true!

On analysing this problem, there is a work around and a solution. Work around is simiple to start with zero as follows.
public enum DefectStatus
{Unknown = 0,Open = 1,Assigned = 2}

Solution is to put [ServiceKnownType(typeof(Enum))] attribute on the service interface contract, and also add the [EnumMember] attribute to every enum value within the Enumeration data contract
[ServiceKnownType(typeof(DefectStatus))]
public interface IDefectMaintenace
{
}

public enum DefectStatus
{
[EnumMember()]
Open = 1,
[EnumMember()]
Assigned = 2
}

Root cause for the problem is defined in msdn as 'enumeration types can be marked with the DataContractAttribute attribute, in which case every member that participates in serialization must be marked with the EnumMemberAttribute attribute. Members that are not marked are not serialized'. Ref is:
http://msdn.microsoft.com/en-us/library/ms731923.aspx

Architecture of SharePoint-2007

This blog is just an abstract of my recent session on SharePoint Overview.

What is SharePoint?
SharePoint is a software platform developed by Microsoft for collaboration and web publishing combined under a single server. These capabilities include developing web sites, portals, intranets, content management systems, search engines, wikis, blogs, and other tools for business intelligence

Architecture of SharePoint-2007
My understanding is graphically represented in the left side pyramid.

Operating System
Windows Server 2003, which uses the Microsoft .NET 2.0 FW, Windows Workflow Foundation. Internet Information Services 6.0 is used for hosting Web applications of ASP.NET 2.x master pages, content pages, Web parts

Database Services
Microsoft SQL Server (either SQL 2000 SP4 or SQL 2005) is used to store all content i.e. data, file and configuration information.

Windows SharePoint Services
Storage: Content databases, Management: Administration pages with deep configuration options, Deployment: Web farms, physical servers, and roles, Site Model: Web application, site collection, and sites

Microsoft Office SharePoint Services
Portal: Templates, people, audience targeting, Search: Search center, cross-site search, Content Management: Authoring, publishing, records management, Business Process: Forms server, line of business (LOB) integration, Business Intelligence: Excel services, Key Performance Indicator (KPI) lists, Report Center

Shared Services
User profile store, Search services, Usage reporting, Excel services, Notification service for generating alerts

Cache in Regular Expressions

The chart illustrates the difference in performance between the code, which relies on repeatedly instantiating a Regex object with the same regular expression pattern to call an instance matching method, and the second, which calls a static matching method.

// BAD: Never reinstantiate the same object

Regex rgx = new Regex(pattern);

return rgx.IsMatch(input);

// GOOD: Take advantage of regex cache

return Regex.IsMatch(input, pattern);

The execution time of the first code is about 15 times the execution time of the second example. The difference in performance is due to the caching of regular expressions used in static method calls. Whereas the first example instantiates a regular expression object and converts the regular expression into opcodes in each of fourteen method calls (one for each element in the string array), the second example performs this conversion only once, on the first method call. Subsequently, it retrieves the interpreted regular expression.from the cache each time the expression is needed.

Only regular expressions used in static method calls are cached; regular expressions used in instance methods are not. The size of the cache is defined by the Regex.CacheSize property. By default, 15 regular expressions are cached, although this value can be modified if necessary. If the number of regular expressions exceeds the cache size, the regular expression engine discards the least recently used regular expression to cache the newest one.

Note that there is a breaking change in regular expression caching between versions 1.1 and subsequent versions of the .NET Framework. In version 1.1, both instance and static regular expressions are cached; in version 2.0 and all subsequent versions, only regular expressions used in static method calls are cached.

Motivation extension

Couple of additional references

http://msvprasad.blogspot.com/2010/07/codeproject-newsletter-19-jul-2010.html

http://www.devasp.net/net/search/display/category75408_page2.html