Caching in .NET

As applications grow it is quite normal to leverage caching as a way to gain scalability and keep consistent server response times. Caching works by storing data in memory to drastically decrease access times. To get started I would look at ASP.NET caching.

There are 3 types of general Caching techniques in ASP.NET web apps:

Page Output Caching(Page Level)
Page Partial-Page Output(Specific Elements of the page)
Programmatic or Data Caching

Output Caching
Page level output caching caches the html of a page so that each time ASP.NET page requested it checks the output cache first. You can vary these requests by input parameters(VaryByParam) so the the page will only be cached for users where ID=1 if a requests come in where ID=2 asp.net cache is smart enough to know it needs to re-render the page.

Partial-Page Caching

a lot of times it wont make sense to cache the entire page in these circumstances you can use partial Page caching. This is usually used with user controls and is set the same way as page level only adding the OutputCache declarative inside the usercontrol.

Data Caching
You can store objects or values that are commonly used throughout the application. It can be as easy to as:

Cache["myobject"] = person;
Enterprise Level Caching

It is worth mention that there are many Enterprise level caching architectures that have come about to leverage the effectiveness caching. Memcache for .net and Velocity are a couple.

In General

You can't really make blanket statements on what you should and shouldn't cache because every application is different. However, you can make a few generalizations that hold true MOST of time. Static elements like images and content are OK to cache. Even a dynamic page that is getting hammered is worth caching for 5-10 seconds, it will make a world of difference to your web server.

Caching overview

Inline Functions in C#

What are They?

In the terms of C and C++ you use the inline keyword to tell the compiler to call a routine without the overhead of pushing parameters onto the stack. The Function instead has it's machine code inserted into the function where it was called. This can create a significant increase in performance in certain scenarios.


Dangers

The speed benefits in using "inlineing" decrease significantly as the size of the inline function increases. Overuse can actaully cause a program to run slower. Inlining a very small accessor function will usually decrease code size while inlining a very large function can dramatically increase code size.


Inlining in C#

In C# inlining happens at the JIT level in which the JIT compiler makes the decision. There is currently no mechanism in C# which you can explicitly do this. If you wish to know what the JIT compiler is doing then you can call System.Reflection.MethodBase.GetCurrentMethod().Name at runtime. If the Method is inlined it will return the name of the caller instead.

In C# you cannot force a method to inline but you can force a method not to. If you really need access to a specific callstack and you need to remove inlining you can use : MethodImplAttribute with MethodImplOptions.NoInlining. In addition if a method is declared as virtual then it will also not be inlined by the JIT. The reason behind this is that the final target of the call is unknown.

More on inline here

Fixing to be Unsafe

The fixed statement is used in the context of the unsafe modifier. Unsafe declares that you are going use pointer arithmetic(eg: low level API call), which is outside normal C# operations. The fixed statement is used to lock the memory in place so the garbage collector will not reallocate it while it is still in use. You can’t use the fixed statement outside the context of unsafe.

Example

public static void PointyMethod(char[] array)
{
   unsafe
   {
        fixed (char *p = array)
        {
            for (int i=0; i<array.Length; i++)
            {
                System.Console.Write(*(p+i));
            }
        }
    }
}

NHibernate.ByteCode.Castle.ProxyFactoryFactory

Anyone seen this error message?

Unable to load type 'NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle'
 during configuration of proxy factory class. 
Possible causes are: 
- The NHibernate.Bytecode provider assembly was not deployed. 
- The typeName used to initialize the 'proxyfactory.factory_class' 
property of the session-factory section is not well formed.

Solution: 
Confirm that your deployment folder contains one of the following assemblies: 
NHibernate.ByteCode.LinFu.dll 
NHibernate.ByteCode.Castle.dll

Well after hours of searching I finally found that if I changed my target build from x86 to x64 the problem resolves itself. This has to go into my top 10 most annoying bugs of all time.