+972 52-548-6969
L2S Prof hardships – getting query duration and row counts
I really want to be able to provide duration & row count for Linq to Sql. It has became a personal goal of mine.
The problem is that there is absolutely no open extensibility points within L2S that would allow it. The solution is… to break down the wall. If you don’t have extensibility points, then I will make some.
And, you know what? I did:
The problem is that it took almost 12 hours to get it to this point, and along the way I had to build a new provider for Linq to Sql. And yes, that is not possible. Not isn’t supposed to be possible, just is not possible.
To get this to work I had to build a hack on top of a crack on top of a very angry duck.
I have been working on this for the last 12 hours, and this is about the most unsupported method that you could find to hook into things (I had to break the CLR type system to get this to work, and the things that I do with reflection are probably amoral in at least three different religions).
The problem with going with that route is that now I have to delay the public beta for L2S Prof. The good thing is that I can now provide additional information about Linq to SQL.
Comments
ha! best post ever!
Wonder if there is anyway to hook in to the client statistics that are generated when queries are run (e.g. the stats the management studio shows when you turn on the 'include client statistics' option).
Imran,
That is probably too expensive to do on tool that emphasis low footprint on the profiled app
That's hilarious. In my experience with L2S, coercive hook ins have become a somewhat typical necessity.
Another reason B&D languages should go away! It makes it hard for you to get to the good stuff (and change it).
Bring on C# 6... which will resemble python with a C syntax.
@"Chris Smith": There is a reason the stuff ayende changed using reflection is private. Imagine everything would be public: People would rely on internals all the time. The .net framework code would be unchangeable in even the simplest detail.
Okay, I'll give in and ask the question: What do you mean by you "had to break the CLR type system to get this to work"?
I'd guess you could do a few things by using transparent proxies and injecting them via reflection, but I wouldn't consider this as a breaking of the type system.
You could also use Reflection.Emit to implement some internal interfaces (hoping that the accessibility flags won't be verified at runtime, of which I'm not sure). This actually is cheating the type system (if it works), but I'm not sure whether this is what you did.
So what's behind that ominous phrase? :)
Fabian,
You can't actually implement internal interfaces using SRE, that is the first thing that I tried, and it doesn't work.
What I mean by breaking the type system is creating a type that lies about what it is.
When you ask it "are you a Foo", it will say yes, and when you ask it, "are you Bar" (totally unrelated to Foo) it will say yes as well.
It is a lying type, basically, and a nasty one that relies on specific usage pattern.
Once again, the blogs tagline is very apt.
Ayende, can you detail the process a little bit more?
In a topic complete away from profiller stuff, I have great interest in such thing
Comment preview