LINQ and Client Server Applications

First of all I would like to apologize for not posting links, for various sources I acquired knowledge from, because a week has passed after reading them and I don’t remember which is which.

Last week I was doing some research for LINQ and how it could be integrated in the applications I develop for my company. There is something on the net, that always keeps bugging me and I prefer to have my own opinion. Always everything is great, but there always seems to missing the parts that things are not good.

In a few words LINQ is an ORM that ships with .NET3 and from what I have seen it is very good. Truly all the great things that have been talked about are there, and even better for me. But something that stroked odd for me, was the fact that there was no single mention about Client – Server applications or known as N-Tier.

I’m not a Web Developer. I develop Smart Client Applications where the notion of disconnected from the data source is the biggest truth.

Every example in LINQ that I had saw, assumed that my application has a direct and steady connection to the data source, exactly like a web application. That maybe true for web in many cases, but in other applications is not. I tried LINQ with just one entity and sub collection, sending it to the client and bringing it back to the server, and all hell broke loose. For just a single entity, logic should be applied on how you should attach your entity to the data context. And I didn’t get to deletion.

There are two ways to manage data in disconnected state. Either you write your own mechanism or use Datasets. I prefer the latest, and especially Typed Datasets for various reasons one of which is the version mechanism that dataset have embedded inside. So I tried to search about Datasets and LINQ and there was just a little.

So I did a little research and found out that …

First of all there are two types of LINQ. LINQ to SQL and LINQ to DataSet. Both do the exact same thing, that is to query collections ,with one huge difference. LINQ to SQL queries collections directly to your data source and LINQ to Dataset queries basically your own dataset. My biggest disappointment was when I found that in the original beta, there was a functionality that converted datasets to entities and reverse, but a developer of Microsoft in his blog, mentioned that they didn’t have the resources to implement it in the current version.

My thought is that when building a framework with business objects and a data access layer that supports its persistence wouldn’t it be great to have Entities-like objects for web and a disconnected version of them for smart clients? This would be, that SQL would be reduces significantly and both application types would utilize the same idea. The only missing link is the mechanism to convert between entities and datasets without having to write extra code.

The above missing link was what I was developing a whole week. It started as a proof of concept, but it became something that I think has great potential, because I like the idea of LINQ especially for Web Applications, which I believe will be optimized even more by Microsoft, I like typed datasets for disconnected Applications and the only thing missing was something that connected them.

This post was like an introduction for my next post, that is the converter project it self.

 

 

 

Reflection BenchMark

For a project I have been developing, over the last week, I have come to utilize a lot of reflection, generics and their combination using MakeGenericType.

So today last day, I began to optimize its performance based on my experience of reflection and the .net world. I have used a lot of reflection so I believe my performance hunches were correct.

I assumed that

1. It is a lot quicker to have a Dictionary of Types instead of calling MakeGenericType
2. It is a lot quicker to have a dictionary of  PropertyInfo instead of using repeatetly GetPropetyInfo
3. It is a lot quicker to have a dictionary of  MethodInfo instead of using repeatetly GetMethodInfo
4. It is better to create static functions that will do your work as a single function, instead of calling through reflection the constructor and then the method.

So tonight I created a Benchmarking program that proved I was right on all 4. What I didn’t expect was the great time MakeGenericType needed to execute.

In the benchmark project I have a TestType.cs without generics and a GenericType.cs with two generic parameters.Each class has a public constructor, an Execute method and a static ExecuteStatic which calls the constructor and the the Execute method.

Because the operations are pretty simple, there will be no milliseconds but average ticks.

The names consist of the following

1. Test or Generic class
2. With reflection or not
3. Instantiating and calling Execute or just call static ExecuteStatic
4. Optimized or not

So here are the results

TestStatic->7
TestInstance->7
TestReflectionStatic->21
TestReflectionInstance->33
TestReflectionStaticOptimized->16
TestReflectionInstanceOptimized->24
GenericStatic->8
GenericInstance->7
GenericReflectionStatic->41
GenericReflectionInstance->75
GenericReflectionStaticOptimized->37
GenericReflectionInstanceOptimized->67
GenericReflectionMake->32
GenericReflectionMakeOptimized->12

The above example is with just one combination of generic parameters used. When I increase the number of generic combinations the results become

TestStatic->9
TestInstance->9
TestReflectionStatic->22
TestReflectionInstance->31
TestReflectionStaticOptimized->16
TestReflectionInstanceOptimized->23
GenericStatic->8
GenericInstance->9
GenericReflectionStatic->40
GenericReflectionInstance->71
GenericReflectionStaticOptimized->37
GenericReflectionInstanceOptimized->66
GenericReflectionMake->31
GenericReflectionMakeOptimized->19

As you can see the performance weakens, probably because of the dictionary and its long keys. String manipulation in .NET is not one of its strongest features.

Another thing is that in my classes, there is only one method, so minor as the difference in optimization as it may seem, keep in mind that the more methods you have in a type the slower GetMethodInfo executes.

In my benchmark I didn’t implement test about properties but I firmly believe that they will not have any difference from methods.

There is no much code in the post, because the optimization is pretty forward. Just reuse Type and MethodInfo as much as possible.

For example the not optimized way is

public static void TestReflectionInstance() { Type type = typeof(TestType); object tt = type.GetConstructor(new Type[] { }).Invoke(null); type.GetMethod(“Execute”).Invoke(tt, null); Stopwatch sw = new Stopwatch(); sw.Start(); for (int i = 0; i < iterations; i++) { type = typeof(TestType); tt = type.GetConstructor(new Type[] { }).Invoke(null); type.GetMethod(“Execute”).Invoke(tt, null); } sw.Stop(); if (Write) Console.WriteLine(“TestReflectionInstance ” + sw.ElapsedTicks.ToString()); times["TestReflectionInstance"] += sw.ElapsedTicks; }

and the optimized way is

public static void TestReflectionInstanceOptimized() { Type type = typeof(TestType); ConstructorInfo ci = type.GetConstructor(new Type[] { }); object tt = ci.Invoke(null); MethodInfo mi = type.GetMethod(“Execute”); mi.Invoke(tt, null); Stopwatch sw = new Stopwatch(); sw.Start(); for (int i = 0; i < iterations; i++) { tt = ci.Invoke(null); mi.Invoke(tt, null); //type.GetMethod(“Execute”).Invoke(tt, null); } sw.Stop(); if (Write) Console.WriteLine(“TestReflectionInstanceOptimized ” + sw.ElapsedTicks.ToString()); times["TestReflectionInstanceOptimized"] += sw.ElapsedTicks; }

My belief is that if you optimize well you code when using reflection, then the performance penalty is not so great but the advantages are many times more significant. I believe this must have been taken into account, when Microsoft developed WPF, WWF and LINQ.

CodeProject Article

The next day while I was out in the sun some thoughts came to me that made me modify the makegeneric comparicon

The Generic Benchmarking is not fair. The practical dilemma is that at any single point of execution is it better to call MakeGenericType for a generic type or to find the type form a variety of pre made types from a dictionary.

So I ran the test using the below codes

Type ii = type.MakeGenericType(new Type[] { typeof(int), typeof(int) });

and the optimized version

Type ii = makedTypes[type.FullName + "|int|int"];

and the results where which

GenericReflectionMake->26 GenericReflectionMakeOptimized->9

This shows that having pre made generic types in a sort of list is far much quicker than calling MakeGenericType

 

Code syntax highlight in blog post

I always write my post using Windows Live Writer.

But there was not any support for any code formatting.

Thanks to Thomas Claudius Huber and his post there is a plugin that just does this job.

XML / NET Serialization

This is my article about XML / NET Serialization.

Karl on ASP vs WPF

Karl Shifflett has posted a very interesting post, regarding what architecture to choose for a new Application Project

His post can be found here and my comments here