Cold, Hard, Cache!

anortham — Fri, 07 Mar 2008 04:04:00 GMT

Don't get me wrong, I really like the Asp.Net Cache (or HttpRuntime.Cache or Uncle Daddy if you want to call it that... you're a little odd aren't you?), but sometimes it just can't be trusted. I mean, I just gave you (the cache) my precious object a second ago and now you claim you don't have it? Did you lose it? Did you sell it on eBay? Did you pawn it to support your habit? Please at least tell me you got a decent price for it.

One of the great things about the cache is also what makes it so untrustworthy. Objects stored there are referenced with WeakReference so if your sever starts getting low on memory GC will collect objects from the cache to free some up. Also take into account that if you put an object in Cache and set it to expire after X minutes, when you go back to retreive it, do you really know how long it's been?

So what we want is a way to tell the cache "I want this specific object (a yellow Tonka dumptruck, metal, not plastic) and if you don't have it, here are instructions on how to get it".

Something like this:

using System; using System.Reflection; using System.Web; using System.Web.Caching; using log4net; public delegate bool Factory<T>( out T instance ); public class CacheHelper { private static readonly ILog log = LogManager.GetLogger( MethodBase.GetCurrentMethod().DeclaringType ); private static readonly Cache cache = HttpRuntime.Cache; private CacheHelper(){} public static T GetFromCache<T>(string key, int cacheTimeInMinutes, Factory<T> retrieveMethod) where T:class { T target = cache[key] as T; if(target == null) { log.Info( "Cache miss for key:" + key + " type:" + typeof(T)); if(retrieveMethod(out target)) { cache.Insert( key, target, null, DateTime.Now.AddMinutes( cacheTimeInMinutes ), Cache.NoSlidingExpiration, CacheItemPriority.Normal, OnRemove ); } } else { log.Info( "Cache hit for key:" + key + " type:" + typeof(T)); } return target; } public static void OnRemove( string key, object cacheItem, CacheItemRemovedReason reason ) { log.Info( "Object removed from cache: Key-" + key + ": Reason-" + reason); } public static void RemoveFromCache(string key) { cache.Remove( key ); } }

Usage would look like this:

List<string> searchList = CacheHelper.GetFromCache<List<string>>( key, 5, delegate( out List<string> instance ) { return SomeClass.GetSearchList( key, out instance ); } );

I call it the code equivalent of "Trust but verify".

Casting options in C#

anortham — Sun, 07 Oct 2007 19:27:00 GMT

What is the best way to cast from one type to another in C#? This question came up at work last week while I was looking through some older code. The code in question was using the C style casting syntax. I have started to use the "as" style cast more often and rewrote it. Then I decided to do some research into the differences between the two styles to find out if one really is better than the other.

The most obvious difference is that a C style case will throw and exception if the cast fails and the "as" style cast will simply return null. So first you need to take into consideration what these differences will have on your code. Will you need to wrap every cast in try/catch blocks? Not if you use the "as" style, but you will need to check for null. What about performance?

I read a dozen or so blog posts on the subject and they seemed to be pretty evenly divided with half insisting that one style was obviously superior and the other half convinced their chosen style was better. That didn't really help so I decided to do some testing on my own.

I've attached a small test project for reference, it will allow you to select the number of casts to perform and the style and return the total time and average for each cast. First let's see what the difference looks like in IL (o is of type object in these examples).

((Person) o).Name becomes: IL_0036: castclass CastTest.Person Person p = o as Person; becomes: IL_0036: isinst CastTest.Person

So there is a difference at the IL level but is one a better performer? I wrote three different test projects, the last of which you will find attached to this post. Why did I write three? Because with each test I was convinced that my results must be skewed because I was not seeing the performance difference I expected. I ran test casting 100,000, 1,000,000, 10,000,000 and 100,000,000 objects many times in difference orders, restarting the application between tests, not restarting between tests, clicking the button with my left hand, clicking with my right hand, every combination I could think of.

What did I discover? It was pretty anticlimactic. In my opinion the difference was completely negligible. That is, negligible if you aren't throwing exceptions when casting with the C style cast. The most stable set of test results I could get were casting 1,000,000 objects. In this case, either style averaged 10.1 seconds total and averaged 0.0101 milliseconds. We're talking about a difference of 0.00005 milliseconds per cast. I can't really get worked up over that. Of course, if you throw exceptions for each C style cast in that test, it's over 10 times slower. That's something to consider!

So will I pick one over the other? The answer is an emphatic "meh". In code I will probably use the "as" style. When doing things in markup related to databinding it's extremely useful to be able to use the C style cast and I will continue to do so.

Alan Northam : C#

Cold, Hard, Cache!

Casting options in C#