It’ll never be as fast as the bare code, but the runtime folks have motivation to do what they can to make it fast enough.

The query is of the form:

Public Function GetbyID(ID as IdT) as EntityIT
Dim q = From e In ContextEntities Where e.ID.Equals(ID) Select e
Return DirectCast(q.Single(), EntityIT)
End Sub

Here ‘e’ is a generic type with the following constraints {Entitybase(of IdT),EntityIT,New} and EntityIT is an interface that inherits IEntity(of IdT)

IEntity(of IdT) is an interface with one member relevant to this discussion, i.e. ID which is of type IdT.

In my test environment, I’ve defined a concrete class called Customer which inherits from EntityBase(of Integer) (thus setting IdT to Integer) and implements ICustomer which inherits from IEntity(of Integer). EntityIT above becomes ICustomer.

I then attempt to retrieve a single customer entity by Id using the above method. The VB code above fails with the following error:

System.InvalidOperationException: {“No coercion operator is defined between types ‘Data.Tests.Customer’ and ‘Domain.Entities.EntityBase(of IdT)’.”}

And yet, the C# equivalent of the above VB code runs perfectly:

public GetByID(ID as IdT) as EntityIT
{
var q = from e in ContextEntities where e.PrimaryKey.Equals(id) select e;
return q.Single() as EntityIT;
}

As you can see the two methods are exactly the same and yet one works and the other doesn’t. Anyone have any ideas why this is the case, ’cause I’m really stumped.

http://www.codeproject.com/KB/cs/genericoperators.aspx

…used LCG, which is the same thing lambda.Compile() does, but he got a 7x slowdown compared to directly adding numbers.

Keep in mind when you measure the speed of a loop like

for (int i = 0; i < 1000000000; i++)
a = a + b;

Where a and b are integers/doubles, the CPU is not well utilized. It spends more time managing the loop than adding b to a. So if this loop is, for example, 4x (or 2x or 7x) faster than calling the delegate…

for (int i = 0; i < 1000000000; i++)
a += LCG_Number_Adder (a, b);

…actually the delegate is much more than 4x slower because the loop overhead is polluting your measurement.

At least using LCG directly has the advantage that it will work in .NET Framework 2.0; lambda.Compile() requires .NET Framework 3.5.

Yeah, I’ve just downloaded your code and checked it out.
But I see that yours is way more complete and advanced.
(btw. brilliant idea to throw exceptions from delegates on types that don’t support math operations)

I also added a link to your project in my post, there are quite a bit of nifty stuff in there :-)

We are; in the MiscUtil code they are in the static Operator class; I’m amazed how similar our code is, actually!

> (Rüdiger Klaehn)
> a factor of 10 or more
No; a factor of roughly 2 if used correctly.

> (Jon Skeet)
> Marc is currently working on a .NET 2.0 version – I’m > not entirely sure how it’s going to work though…
it uses Delegate.CreateDelegate on the MethodInfo; it will use the necessary “op_Foo” methods if they exist (also had to provide the missing operators for int, float, etc), also with support for Nullable (lifted operators).
Fully working now for all primatives, all inside 2.0 ;-p
(but like yourself, I started with 3.5 Expressions)

Marc

Why aren’t you guys storing the compiled delegate in static vars like I do in my version?

Just initialize the delegates in the static ctor (or directly on the static fields)

and then simply call the delegates from your Add/Subtract/Div/Mul functions.

[edit]
Apparently you do, I didnt see that the code on the page was just sample code..

http://pobox.com/~skeet/csharp/miscutil/usage/genericoperators.html

These are used in Push LINQ and my Range classes.

Marc is currently working on a .NET 2.0 version – I’m not entirely sure how it’s going to work though…

Doh, please disregard that brain fart :-P I shouldn’t post on my vacation, I’m probably still drunk from yesterday ! ;-)

I was thinking about how the CLR doesn’t dynamically _re-JIT_ stuff depending on context (as far as I know) but that doesn’t really bear on this case. Of course the CLR will JIT to native the first time hitherto uncompiled code is called.

/Mats

“Since delegate invocations are never inlined by the CLR”,

Do you mean inlined by csc? Because I thought the CLR didn’t do JIT compilation (actually I thought it did until recently when someone told me it didn’t :-P )

/Mats