Quickly Trim all model's Properties - Reflection Vrs Fasterflect

I've had some great feedback from Buu Nguyen author of the Fasterflect library. He supplied the feedback below as well as some sample code, which I have incorporated into the code base. 

Buu Nguyen says:

Fasterflect only speeds up invocation operations, not query (aka lookup) operations.  In fact, query operations in Fasterflect are convenient wrapper for .NET reflection, so using them will cause the code to run slower.

Suggested usage: avoid query operations if you don’t really need them;  move the GetProperties out of each iteration because it is the same for all methods and thus makes it hard to see the performance difference when using Fasterflect.

The delegates should be reused instead of being regenerated every time – the latter will make the code run even slower than the normal Fasterflect API.
Suggested usage: use a dictionary to cache the generated 

The main change to the code was to cache the call to type.GetProperties(). So instead of calling the GetProperties() method directly a call is made to a caching component which ensures that the GetProperties() call is only made once per type.

Also, as Buu has suggested, the calls for generating the delegate setters and getters are now cached into a static dictionary as well.


Test Methods (2-4 using cached call to type.GetProperties() ):

1. Long Hand - No reflection.
2. Initial code - normal reflection
3. FasterFlect m1 - Uses the FasterFlect library
4. FasterFlect m2 – Uses the FasterFlect library’s delegates approach

Results

So here are the results (over 1 million object trims):

Long Hand Trim	00:00:01.4150000
Initial code	00:00:08.8280000
Fasterflect m1	00:00:04.8190000
Fasterflect m2	00:00:02.9920000

Ok, now we are seeing Fasterflect perform nearly twice as fast as reflection and about 3 times as fast when using the delegate method of Fasterflect.

It also appears that the delegate method of Fasterflect is only about twice as slow as the long hand trim.

Download the source code.

Long Hand code

Property Cache Helper

Initial code

FasterFlect Method #1

FasterFlect Method #2

Set Default Outgoing Repository with hg (Mercurial)

Firstly if you are new to Mercurial check out http://hginit.com/ its a brilliant little Mercurial tutorial.

When creating a hg repository locally, at some point later, I often need to set the default outgoing repository to push out my changes.

Creating projects locally using hg (hg init) without cloning from anther location is ideal for playing with new projects locally and having your source code version controlled.

There are so many times where I spend about 10 minutes going down a path then find out that I don't want to continue. With mercurial or git as a local version control system, you can simply revert back your changes to the last commit.

When the time comes to publish your changes to the world, setting up a default outgoing repository in hg saves a lot of typing.

Here is how to do it

1. Go to the .hg folder in the root of your repository
2. Create a new file called "hgrc"
3. Enter your default outgoing repository as show below.

That's it. Now you can just enter "hg outgoing" to see the list of change-sets that need to be pushed to your default repository and "hg push" to actually push out your changes.

Codeplex now has Mercurial as an option for version control.

Here is a copy paste sample for the Jobping Url Shortener project on codeplex

[paths]
default = https://hg01.codeplex.com/jpurlshortener

Quickly Trim all your model's string properties – Speed results

Update: Posted another follow up with feedback on the usage of Fasterflect

With my Quickly Trim all your model's string properties post causing quite a stir (2 comments), I have decided to post a follow up and actually test the speed.

For the actual benchmarking I used a slightly modified version of this nice little class http://www.yoda.arachsys.com/csharp/Benchmark.cs, which I found from this page http://www.yoda.arachsys.com/csharp/benchmark.html

I tested 4 different methods that use reflection to trim all the string properties on an object and the 'long hand' method that does not use reflection at all.

Test Methods:

1. Long Hand - No reflection.
2. Initial code - with the GetIndexParameters call removed (not needed)
3. Initial code with linq – Initial code but using linq to select the properties to process
4. TypeDescriptor– used the TypeDescriptor class to get the property list
5. FasterFlect m1 - Uses the FasterFlect library
6. FasterFlect m2 – Uses the FasterFlect library’s delegates approach

Results

So here are the results (over 1 million object trims):

Long Hand Trim	00:00:01.4220000
Initial code	00:00:07.7130000
Initial code with linq	00:00:10.7270000
TypeDescriptor	00:00:14.2340000
FasterFlect m1	00:00:06.1330000
FasterFlect m2	00:00:06.1830000

Surprised? I was. Firstly, the refection code varied from 7 - 14 times slower then the direct code, this wasn't a surprise more of a reminder that you really need to be careful when using reflection in your code base.

I knew my initial code would perform better then trying to filter for properties before doing the work. Filtering the properties first using linq or any other means, basically results in another loop over the properties on the object. So the more properties you have on your object the worst this method will perform.

But I was quite suprised with the TypeDescriptor. I had hopes that this would perform better then my initial code, as according to the documentation this method actually caches the meta data about objects. I am suspicious I haven’t used it to its full potential…

The other surprise was that the delegate method in fasterflect is actually slower then the normal method. Again, someone may well point out how to implement this better. The other note is that fasterflect was only able to achieve an 80% reduction. I was hoping for more.

Anyway interesting stuff, if someone has another fast method to achieve the same results let me know I’ll take it for a test drive.

Download the source code.

Long Hand code

Initial code

Initial code with linq

TypeDescriptor

FasterFlect Method #1

FasterFlect Method #2

Jobping Open Source URL Shortener. Goes to Version 0.5

We have updated our url shortener for Jobping. jobp.in has moved along to Version 0.5. While maintaining as little features as possible!

Since the initial version we have placed a restriction(web.configurable) on the domain names that the shortener will shorten. We did this so only domains under jobping.com would be processed by the shortener. We wanted to maintain the integrity of the jobp.in domain. With this in place you can be sure that if you click a link shortened by http://jobp.in  it will always go to our site jobping.com site.

A database migration to add case sensitivity to the short url column was added to the migration scripts. Previously this needed to be added manually after the install. Now it all runs out of the box, just x-copy, point it to a database and your good to go.

This version also includes a new custom style, which looks awesome by the way, for the site. The interface is now slick and styled inline with our main site Jobping.

The new version can be downloaded from codeplex here: http://jpurlshortener.codeplex.com/

The introduction blog post can be found here: http://markkemper1.blogspot.com/2010/05/announcing-jp-url-shortener-open-source.html

Quickly Trim all your model's string properties

While developing a internal application for http://www.jobping.com using ASP.NET MVC 2 I had the old problem of trimming all string properties on the model before saving to the database.

My first reaction was to start adding trim() everywhere but this causes problems when properties are null. Checking for null pushed me over the edge and I quickly came up with some code to do what I needed via reflection.

The code is below, it will quickly trim any string properties on your model object (no promises of course)

With this code, you can simply trim all string properties, lets say you have a blog model object called myBlog, just go myBlog.NullSafeTrimStrings(), job done.

Be warned this is quite an expansive little operation. DO NOT go putting it in a for each loop

Announcing: Jobping URL Shortener. Open source MVC.NET 2 C#

Jobping is a niche job site for listing Microsoft related vacancies (Australia only for now). Jobping sends out tweets (1 for each job posted on the site) and we wanted to brand our short URLs e.g. http://jobp.in/g.

We could have used bit.ly pro but the pro accounts are in invite only (check it out though, they offer additional reports etc). We only very basic requirements we decided just to go ahead and implement our own url shortener.

Own URL shortener has a ‘less is more’ approach and was the quickest solution for us to get our own branded short URLs.

The site requires IIS 7, .net 3.5, asp.net mvc 2 and a mssql database.

Apart from creating our own URL shortener we also wanted to make it open source to help out other people looking for a bare bones URL shortener. You can find the source code on Codeplex here: http://jpurlshortener.codeplex.com/

For anyone new to MVC or interested in how it works, I’ll go through the basic functions of the site below.

Technical Description

The URL shortener has 2 functions

1. Create a new short URL
2. Redirect anyone requesting a short URL

Part 1 – Creating a short URL

Get request for the root URL “/”


This method on the Home controller simply returns the view. The view contains a form that allows someone or something to post a long URL and have a short URL returned.

The view for the GET request is shown below (This uses a common master page).

 

When the form is posted back to the “/” route the follow method is invoked.



You can see that this method is attributed with Http Post, this means that this method is only applicable when a HTTP Post is issued to the server. The method first checks if a short URL already exists for the long URL requested, if so the existing short URL is used. Otherwise a new URL object is created and saved into the database. You will notice that we first create a URL object in the database then use the Identity column as the seed to generate our short URL. Once we have generated our short URL we save this into the database. These operations exist inside a transaction to make sure we do not end up with a blank Short URL column in our DB.

The other point is that if the format parameters is present and contains the value “txt” a text only view is returned. This allows the same method to be used for API calls. Clients simply pass the format parameters and read the short URL from the result.

The Result view for the html result is shown below (This uses a common master page).


The Result.TXT view is shown below, here no master page is used and the only the short URL is returned


I skipped over the actual creation of the short URL. The creation happens in our ShortUrlEncoder object. Basically this object base encodes the long integer value using a series of 64 characters that are suitable for URLs.

Here is a sample of what our encoder does to some sample numbers (in powershell)



We simply just append the output of the encode to the current domain name, so “qCc” would be a short URL of “http://jobp.in/qCc”

2. Redirect anyone requesting a short URL

The redirection is really quite straight forward, we simple route all that are not “/” to our “Follow” method on the Home controller.



As you can see, we simply retrieve the short URL from the database. If its not found, then return a 404, otherwise we redirect the user to the long URL destination. You can also see that we are using the current URL as the base when forming our short URL.

That’s it for now, you can check out the code on Codeplex here: http://jpurlshortener.codeplex.com/
We would welcome any feedback on the project.