So today I was perusing my blog list and ran across a blog by Rick Strahl (Dynamic Delegates with Expression Trees) which is referencing this post by Nate Kohari (Fast Late-Bound Invocation with Expression Trees).

I first just thought it was a very interesting post and thought, “wow, next time I have to do something requiring a ton of reflection method calls I’ll have to remember this”. I took off with the family for the day and sometime during the day the idea popped into my head about trying it to read property’s values (since they are actually just a method call under the hood). And I do have the perfect place to try and spike this idea…

One of the things I’ve done to the i4o library is try to reduce the calls to reflection whenever possible. And the only one left that I couldn’t get past was having to use the PropertyInfo’s GetValue reflection call to get at a value for creating the property index. This generally isn’t a big deal because we only have to do it once, however it makes the initialization of the IndexableCollection<T> fairly expensive.

So I decided to spike the idea of using the DelegateFactory from Nate’s blog to read an object’s property values. And below I’m including the project that I spiked to test this idea out.

It compares how fast we can read values out of an object’s property by first using reflection and second using the dynamic delegate.

If you read Ricks post above, he mentions how the dynamic delegate idea is a little reflection expensive up front. However it only happens once and I ran a couple of tests…(p.s. i noticed a small flaw in my timing, however I don’t want to re-zip & re-upload the spike… so if you see the timing flaw, cool…)

I noticed that after about the first 5000 reads the expense of the heavy up front reflection from DelegateFactory started to become negligent. And the more reads the more powerful the new reading strategy became. Take 1/5 million reads for example… normal reflection reading took .78 seconds, while the delegate reading took only .03 seconds which is a substantial increase.

After that I spiked it in the i4o project and proved that this could significantly increase the index build time of the an IndexableCollection<T>. I shelved the spike and am having Aaron take a look at the idea. We’ll see, I haven’t come up with any reasons why this could cause any issues, so it may be included…

We've removed the IndexableAttribute from the i4o library and replaced it with the IndexSpecification<T>. Below I'll explain how you can add/remove/change the index for an IndexableCollection<T>.

Let's show several examples on how to create an IndexableCollection<T>.

Given any enumeration of objects you can translate into an IndexableCollection<T>. For the examples below we're going to use an enumeration of the System.IO.FileInfo class. We are going to index the list of FileInfos by file Extension and weather the file IsReadOnly or not.

Setup the list:

// Get our thing to index
string dir = @"C:\Windows\System32\";
var fileInfosFromDir = (from f in System.IO.Directory.GetFiles(dir, "*.*", SearchOption.AllDirectories)
                       select new FileInfo(f)).ToList();

Can create the IndexSpecification...

// Create the index specification
var spec = new IndexSpecification<FileInfo>()
   .Add(i => i.Extension)
   .Add(i => i.IsReadOnly);

// Turn the list of files into an Indexed collection of files
var indexedFileInfosFromDir = fileInfosFromDir.ToIndexableCollection(spec);

Create IndexableCollection<T> without IndexSpecification<T>:

You are not required to specify and IndexSpecification<T> when creating the IndexableCollection<T>. You can translate the list into an IndexableCollection<T> and add properties to index after the fact. EX:

var indexedFileInfosFromDir = fileInfosFromDir.ToIndexableCollection();

// Specify the properties to index dynamically (more late bound)
indexedFileInfosFromDir
   .CreateIndexFor(i => i.Extension)
   .CreateIndexFor(i => i.IsReadOnly);

Swap one IndexSpecification<T> for another:

If you want to completely swap out the index at run time, you can give the IndexableCollection a new IndexSpecification

var list = new List<FileInfo>();
var indexedList = list.ToIndexableCollection();

indexedList.UseIndexSpecification(
   new IndexSpecification<FileInfo>()
   .Add(o => o.Directory)
   .Add(o => o.Name));

I think that should cover most of the general cases. Hope this helps...

Recently I was added as a developer to the i4o codeplex project by Aaron and last night I made my first commit.

There were a few pretty big changes to the library. I'll highlight some of them below, and in a couple future posts will describe in a little more detail how you can use these features.

Removed the IndexableAttribute:

This was removed for two reasons.

• It did not allow you index objects you didn't own.

Say you want to index a collection of System.IO.FileInfo objects. Since that's owned by the .Net framework, you can't apply an attribute to the properties of the class you want to index.

The solution to that was to allow adding indexed properties dynamically, however you had to give it a string representing the property name, which leads into the second issue...

• Didn't provide any compile time checking or refactor support for properties using the dynamic add/remove methods.

If you refactored a property and forgot to rename the string to match the refactor you would end up with a runtime error.

To resolve the two issues above I've introduced the IndexSpecification<T> (I'll describe how to use it a later post)

Performance tuning:

Although we haven't enhanced the Linq support for IndexableCollection (should come soon), I was able to eek some performance by doing some internal caching of property types and a few other tweaks resulting in the Index creation becoming about 30% faster...

Fluent interface for managing the Indexes

The last big change which fits in with the IndexSpecification<T> is the Fluent interface for dynamically adding/removing properties to be indexed. One short example could be:

Follow up to my post on i4o & Silverlight (compiles first try)...

I took a stab at porting the i4o unit tests to Silverlight which was quite a bit more work than I initially expected.

After creating a Silverlight Unit Test project and linking the original test files into the Silverlight project, I compiled...

• First the VB using statement wasn't even needed, so I removed that. using Microsoft.VisualBasic;
  
• Second there is no System.Diagnostics.Stopwatch() class in Silverlight, so I basically implemented a quick one using DateTime to get the unit tests to compile in Silverlight. Here's the class, except the Frequency property has been commented out (didn't spend time to figure how to make that correct, or what is correct???)

public class Stopwatch
{
	private DateTime _StartUtcDateTime;
	private DateTime? _EndUtcDateTime;
	private bool _IsRunning = false;

	//public static readonly long Frequency { get { throw new NotImplementedException(); } }
	public static readonly bool IsHighResolution = false;
	public Stopwatch()
	{}

	public TimeSpan Elapsed
	{
		get
		{
			if (_EndUtcDateTime.HasValue)
			{
				return new TimeSpan(_EndUtcDateTime.Value.Ticks - _StartUtcDateTime.Ticks);
			}
			else
			{
				return new TimeSpan(DateTime.UtcNow.Ticks - _StartUtcDateTime.Ticks);
			}
		}
	}

	public long ElapsedMilliseconds { get { return Elapsed.Milliseconds; } }
	public long ElapsedTicks { get { return Elapsed.Ticks; } }
	public bool IsRunning { get { return _IsRunning; } }

	public static long GetTimestamp()
	{
		return DateTime.Now.Ticks;
	}

	public void Reset()
	{
		_EndUtcDateTime = null;
		_StartUtcDateTime = DateTime.UtcNow;
	}

	public void Start()
	{
		_EndUtcDateTime = null;
		_IsRunning = true;
		this._StartUtcDateTime = DateTime.UtcNow;
	}

	public static Stopwatch StartNew()
	{
		var w = new Stopwatch();
		w.Start();
		return w;
	}

	public void Stop()
	{
		_EndUtcDateTime = DateTime.UtcNow;
		_IsRunning = false;
	}
}

The only other issue that came up was some of the Stopwatch dependent tests happened so fast that they would fail intermittently... the quick hack/solution for this was to up the iteration count of whatever they were testing.

After all the above taking care of all the above issues, I was able to get the unit tests to pass.

So I've been thinking lately of a problem that we will be solving at work that will require a user to follow these steps...

1. User selects some set of data to work with
2. Some number crunching has to happen to give the user a report like interface
3. User analyses that data, tweaks some value and will basically go to step 2 above...

This application is being build with Microsoft Silverlight and in thinking about how to make step 2 above as smooth and responsive as possible, I thought "Hey, what about i4o?"

A quick Google for "i4o Silverlight" and without digging too far I basically found nobody had tried it, or at least tried and told about i4o in Silverlight. So I thought I'd give a go...

Step 1: Go get the code from from codeplex/i4o. I downloaded the latest source bits.

Step 2: After extracting the .zip...Open up the project i4o.sln

Step 3: Add a new Silverlight class project

Step 4: Now use the "Add existing item" option to add files to the Silverlight project. Browse to the i4o project folder to select the 3 i4o class files. You can add those to you Silverlight project as is or use the "Add as Link" feature to share the code across the platforms.

Step 5: once you've add the files to the Silverlight project final step is to "BUILD" the solution...

What's that you say? "That's all there was to it?" YA, my thoughts exactly, the project just compiled on the first try...

DISCLAIMER: I haven't tried to use it yet... It's late and this idea popped into my head distracting me from getting to sleep. So I tried it and am quite satisfied for now.

Up NEXT: Don't know if I'll do this sooner than later, if at all, but figure out how hard it would be to port the existing unit tests to see how they run in Silverlight...