Hi. Firstly, I'm really glad I found this module, I started writing my own simple profiling module before I found this and it looks really good.

The only thing is, I can't see how it's possible to do anything with the data it gives, because the results don't tell you where in Orchard the profiling results are actually coming from. There's that "call stack" display but it says things like:

ExecuteReader GetResultSet DoQuery DoQueryAndInitializeNonLazyCollections LoadCollection Initialize Initialize OnInitializeCollection

... Which is basically meaningless, it's just telling me that a reader is being enumerated, it tells me nothing about where that query originated.

So is there any way to get MiniProfiler to display a full call stack, preferably with line numbers?

Something that just helped me a lot is commenting out this code in ShapeProfiling:

            if (shapeMetadata.Type.Equals("Zone") || context.Shape.ContentItem == null)
            {
                return;
            }

I'm not sure why you're only interested in content shapes, but it's really useful to see the whole tree of shape building, it's showing me really clearly where to optimise.

BTW; I've started a fork to try and add the ideas I had in my own profiler, and also try and optimise the profiling itself. For a start I think stuffing all the profile steps into HttpContext might not be such a good idea; why not just have an IProfilerService dependency that stores its own dictionary, which will naturally be instanced per request anyway?

Too much tree profiling makes too much noise. I'm planning to parametrize what will be displaying. Currently there is no need to.

I don't know, I'm finding the output really useful; you get a really detailed picture of everything that's going on. Actually in my fork I added profiling to a whole bunch of things (handlers, drivers, event bus) and I'm starting to get a really detailed picture of program flow and what's causing the bottlenecks. I found the vanilla set of results weren't really giving much, as actually the shape building part is only a small fraction of a normal request; the really interesting (and time consuming) stuff happens prior to that; and mainly in drivers and handlers, although the event bus covers a lot more stuff as well (e.g. authentication, rules).

I will try to check it out then :)

What do you think about my original comment, I seem to be unable to see where the SQL queries actually originate in the code. Is it possible to get a class / method at least?