2

In my application there is a "loader" executable (let's call it "Loader.exe"). It searches a specific folder for DLL files and loads them one-by-one. Then the user can choose which plugin to run (plugins have windows and business logic). This is a kind of a plugin architecture I have currently implemented.

The problem with that is that none of the run-time explorer tools for WPF and profilers can see what is happening inside the loaded DLLs. E.g. the CLR Profiler does not gather any data at all.

Is there anything I could do to fix this without rewriting the DLL loading part of the project? And, frankly, why don't those profilers see the loaded DLL code? VS debugging works great in those.

Jefim
  • 3,017
  • 4
  • 32
  • 50
  • Since VS debugging works great in those, you can use random-pausing to find performance problems. (http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in-linux/378024#378024) It's quick, dirty, cheap, and (IMHO) best. – Mike Dunlavey Nov 22 '10 at 16:16
  • Yes, the debugger works fine. And can be used to do some 'profiling'. Yet I am dealing with complex code that is not so easy to debug all the time. In addition, debugging things and method calls that can be triggered with WPF bindings is not so obvious. All in all, I like the VS debugger and I agree it can be used to do something, but a working profiler would be a much better option for me to get an overview of what is happening and which methods are not so efficient. – Jefim Nov 23 '10 at 07:27
  • @Jefim: MS products in general are very high quality, but profiling tends to suffer from general misconceptions. It shows in your use of "overview of what is happening and which methods are not so efficient". Methods generally aren't inefficient, and profilers don't really tell you what is happening. They just measure stuff. If you want to remove wasted time, you have to think more like a tree surgeon, of the call tree. What stackshots tell you is what activities are taking the most time, and which statements (not methods) to concentrate on. – Mike Dunlavey Nov 23 '10 at 16:26
  • ... and complex code is not an issue. I routinely identify problems in our app consisting of over 30 .net plugins, with the stack around 30 levels deep. Typical problem: 50% of time unnecessarily going into extraction of internationalized strings from resources. That's what I mean by "activity", and there are no obviously inefficient methods. I daresay there's no profiler that would have a *clue* to finding such a problem. – Mike Dunlavey Nov 23 '10 at 18:34
  • Well, I have to admit - you sound very convincing. And even though the initial question is still unclear I can say that I got something cleared up in my head. Of course the debugger in VS is the main tool to identify problems and trace their sources. It is just that sometimes I hope that there is something out there to minimize the debugging hours of mine. E.g. having a complete statement call stack (user code) between two points in time seems like a nice opportunity to get an overview. And breakpoints and call stack in VS do not sometimes feel like the right tool for it. – Jefim Nov 24 '10 at 07:24
  • In the end - I may not need a profiler as a performance tool. I need a tool that can easily draw call trees of some sort. And the "profiler" word seemed like something that could help with that thing. A disappointment followed when I saw that those tools do not work the way I imagined (meaning the DLL problem). The same goes for WPF visual tree explorers (they cannot see anything inside windows contained in another assembly). – Jefim Nov 24 '10 at 07:29
  • 1
    By your question it seems that the loader is a separate process? If it is, then that is why your profiling yields nothing - the process is simply not being profiled. If it is the same process, then most .NET profilers should be able to give you a trace tree or whatever you need. What profilers have you tried? – S.Skov Nov 24 '10 at 13:20
  • Well, for example, if I use the CLR Profiler 2.0 it does not give ANY data at all. Eqatec gives a better result, yet still not much data there. There is no additional processes though. Sometimes some threads may be there, but no other processes :( – Jefim Nov 25 '10 at 11:31
  • Oh, wait, I just tried again - Eqatec only gives a better result until I launch a plugin - then my app crashes. Some strange exception (does not appear without the profiler running). And I did not find a way to attach to a process from Eqatec. – Jefim Nov 25 '10 at 11:53
  • Try my profiler (xteprofiler.com), if it doesn't work, I will fix it so it does. – S.Skov Nov 25 '10 at 15:30
  • When you say 'Dynamic dll' do you mean dynamic code, as in using the DLR and Expando object et al? If so, then that is why your profiling does not yield any results, as dynamic objects/methods can not be profiled through the profiling API. – S.Skov Nov 25 '10 at 15:36
  • @S.Skov - I just tried your profiler - it works great! Thanks for the info (I count find your profiler through search). I consider the question solved for me. Could just post your profiler link as an answer so I can accept it? – Jefim Nov 26 '10 at 07:09
  • Glad to hear it worked for you and yes indeed, I need to profile my SEO techniques..;) – S.Skov Nov 26 '10 at 10:16

1 Answers1

0

Try my profiler www.xteprofiler.com , if it doesn't work, I will fix it so it does.

S.Skov
  • 707
  • 4
  • 8