Updates for dynamic ORMs #5

Merged
merged 4 commits into from Dec 12, 2013

2 participants

@amirrajan

Here we go! Frans. I can't thank you enough for that insight. Converting literally 2 lines of code had a significant increase.

Here is what I have:

  1. I've included a bench mark for as close to the DLR as I could possibly get. The "typeless dynamic object" is a raw dictionary that reads straight from the data reader. This probably as fast as you can expect a dynamic object plus the DLR.

  2. The next one is a typed dynamic class, without change tracking.

  3. The final one is what I originally submitted (unaltered), but with the performance bottle neck that you found. Thanks again for the help. You didn't have to do that, and you didn't have to spend the time you've already spent. So it truly is appreciated (yay OSS).

I still think the stopwatch should be after the enumeration for these dynamic objects. It's important to show what kind of overhead the DLR adds.

@FransBouma
Owner

:)

Will merge tomorrow (thursday) if I have time. I have migrated locally to the 2008+ example db from microsoft, so some things changed locally, so merging will not be smooth I recon.

I'll also include enumeration on the results in all other results, that's rather easy, I have factored out the check in a separate method locally. Good point on the DLR overhead being visible this way!

Glad you could fix the slow down :) It was not a lot of effort, just attach the profiler, record snapshot, take a peek and it was easy to spot :) Don't know if you use profilers, but they can help a lot (I used dottrace, there are others like ants. )

@FransBouma FransBouma merged commit ad9a984 into FransBouma:master Dec 12, 2013
@FransBouma
Owner

I've merged it, there were merge conflicts, I tried to resolve them. There are 3 tests for Oak, 2 of them are without change tracking. I want max 2 per ORM, so which one do you want to keep from the non-change tracking?

@amirrajan

Note with regards to the enumeration speed across the dynamic type: hydration of the dynamic object is done the first time a property is accessed and happens once on Oak's underlying dynamic construct. Subsequent enumerations and property access happen at compile time speed.

I kept the dto one, as the differences were minimal, only enumerating the sets showed some differences (24ms vs. 240ms). Commited into the next push.

Using a typeless dto/dictionary backed object does not take have this late bound behavior (which is why it's 10x faster to enumerate).

I want max 2 per ORM, so which one do you want to keep from the non-change tracking

I think you should keep both of them. Here is why.

There are 2 without change tracking specially to show what the difference is between a typed dynamic object and a typeless dynamic object. Many .Net developers (when they think of dynamic), think of ExpandoObject or ViewBag or some form of dictionary (such as DataSets or IDictionary<string, object>). All these implementation of dynamic are essentially typeless. Meaning, you can't ask an ExpandoObject if it's a SalesOrderHeader, because it will never be that.

The two test without change tracking help clarify the difference between a typeless dynamic object and a typed dynamic object. It shows that an object can be typed, but still dynamic. You can say entry is SalesOrderHeaderDto and have it return true.

At the end of the day it's up to you. If you still feel that you want to limit it to two, I'd remove the typeless example and keep the typed/DTO implementation. Personally, I've had too many conversations with developers about dynamic typing and I always end up asking the following question:

"Have you tried dynamic types in C# or are you just using typeless objects? Just because you used the dynamic keyword doesn't mean you are using dynamic typing."

Keeping both examples shows the difference between using typed and typless objects (and the trades offs that come with it).

@FransBouma
Owner

Ok good point. I've refactored a lot of code. It's now much easier to add benchers. I'll add the other code you added manually, so you don't need to create a pull request.

@FransBouma
Owner

I kept the dto one, as the differences were minimal, only enumerating the sets showed some differences (24ms vs. 240ms). Commited into the next push.

@amirrajan

Cool. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment