new feature suggestion
DanAvni
Posts: 72 Bronze 2
on ants 4 please add the ability to view the MS .NET framework code when profiling. so when i click on a method that is part of the framework i will see the code. i know there is an option to debug into the framework source code so why not show the code in the profiler?
Dan Avni
Comments
Thanks for posting. The problem here is the lack of PDB files. Without PDB files there's no way to map back to any source code, where it exists. Now that we've acquired .NET Reflector we could potentially do something with the decompilation technology in this, however profiling the framework methods at this level of detail would lead to a significant performance penalty so you probably wouldn't want to do it all the time. So, certainly something we could consider adding in the future.
Thanks,
Bart
Principal Consultant
bartread.com Ltd
Scott.
If you have the PDBs you might try copying them alongside the framework assemblies as an interim fix. You might find this works (OTOH it might not if the PDBs don't contain line level offset mappings, but possibly worth a go). If it does you'll still need to point ANTS Profiler at the source files, although once you've done this for one file you should find it works for all of them.
Thanks,
Bart
Principal Consultant
bartread.com Ltd
I just tried this (copying the PDB to the framework directory) and it doesn't seem to make a difference, but I am not sure if I am doing the right thing. I have struggled a bit with getting the reference source working, but it seems to work now in Visual Studio, and I can step from line to line in the .Net code, so I assume that means the the line level offset mapping is available. Do you have any suggestions that I can try?
Thanks,
Scott.
Does copying the PDB files make the framework methods appear in bold in the tree and grid? If so this means ANTS Profiler has recognised that source code information is available. You then just need to selected one of the methods and click on the link to tell it where to look for the source file (it should then find most of the others automatically). If it's not showing the methods in bold, then for whatever reason it's ignoring the PDB files. I'll have a chat with Andrew about it and see what the issue is likely to be.
Thanks,
Bart
Principal Consultant
bartread.com Ltd
The methods are not appearing in bold. I copied the System.Data.pdb file to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727.
Scott.
Principal Consultant
bartread.com Ltd
I just asked Andrew, who developed the profiling engine, why this doesn't work. Here's his response:
I'm not entirely sure, and I don't have the pdb files to try this out. The PDB file does need to go in the right directory so that we'll find it. This should be the directory containing the DLL that is actually loaded into .NET, which for the corlib DLLs should be the framework directory.
You could also try the current directory as seen by the application: maybe we're just not searching the right directory. In theory we should be doing the same thing that visual studio does, although it uses ICorDebug and we go in through the metadata interface so there's probably some difference.
Andrew.
It might be worth trying some of these suggestions. If you get nowhere I'll add it to the list of things we'll look at for a future version. Be aware that if it does work and you're running with line level timings enabled it's going to produce an absolutely gargantuan quantity of information. I hope you're running on a 64-bit machine with a 64-bit OS and a lot of memory.
Thanks,
Bart
Principal Consultant
bartread.com Ltd
I just tried putting the PDB in my own application's directory and it worked! Unfortunately, I have to tell it where each file is, but at least I am now able to get the information. BTW, you weren't half kidding about the performance!
I will make the request that future versions of ANTS be able to use the symbols directory configured in VS and also figure out the files better. Also, based on this, I am really hoping that Red Gate will seriously consider re-adding the ability to disable the profiler (http://www.red-gate.com/messageboard/vi ... php?t=7592). Otherwise, it will take forever to get to the point where we actually need to profile when doing per-line profiling on the System.Data classes (our logon screen took about 10 minutes to come up [due, it seems, to reading the app.config file], whereas normally it will come up within a few seconds when running under the profiler without System.Data, and in less than a second with the profiler disabled in ANTS 3).
Anyway, thanks a lot for your help.
Scott.
I'd expect that since System.Data is installed in the GAC, ANTS Profiler wouldn't be looking for the PDB in the .NET Framework installation directory. It may be useful to know a neat trick I found for creating a global PDB directory. It's not as good as a symbol server in that you cannot have multiple assembly version PDBs, but it's handy in a pinch!
No problem. The difficulty with PDB files is that unfortunately the debugging API doesn't give us much control over resolving them, in fact I'm not sure it gives us any, which is a pain in the butt basically. Ideally we'd like to be able to support the kind of resolution we do for source files. Incidentally I'm surprised you're having to locate all the source files. I would have thought you might have to do it for files in different assemblies, but for every file in a given assembly is a bit much. This suggests our resolution algorithm has a hole or two in it. We'll look at it again.
And yes, the line level performance is really going to hurt. I'm not sure what impact disabling and re-enabling the profiler would have on the way we collect data, whether it would impact performance adversely, or whether it would cause problems with the accuracy of the results. Possibly all of these. I'll have a chat with Andrew about it, but realistically I don't see that making a reappearance before version 5. I'd recommend using method level timings to initially isolate problems, but still with the framework PDBs so you can inspect the source code, then when you have a better understanding of what the framework is doing, which should still be possible by stack trace inspection, and comparing time for a method, with its time with children, do line level timings only with your source code. You should find collecting method level timings is very fast, particularly if you only analyse methods with source--just include the PDBs for the parts of the framework you're interested in.
Hope that helps.
Thanks,
Bart
Principal Consultant
bartread.com Ltd
I find the fact that AP4 is a lot slower than AP3 quite puzzling - we rewrote the achitecture so that it should do a lot less than AP3 (even when AP3 is disabled) and we have found very few cases where AP4 is not faster than AP3 let alone much slower.
Having said this due to the reachitecture we do push a lot of data down named pipes - we have found one or two virus scanners with on access scaning enabled can significantly impact the performance of the profiler.
Do you run any virus scanners on your machine? If you do, could you temporarily disable it and try profiling then (perhaps without the framework pdb's to begin with
[Edit: Sorry I didn't spot the bit in your other post where you said you had already tried this]
Thanks,
James
Head of DBA Tools
Red Gate Software Ltd
http://www.red-gate.com/MessageBoard/vi ... php?t=7592
Principal Consultant
bartread.com Ltd
Although I was able to disable the "File System Auto-Protect" of my anti-virus (which made no difference, as noted in the other thread), I was told by IT that there is no way to disable it 100% without completely uninstalling it from my machine, so I will not be able to give you a complete answer. If it makes any difference, I do not see any activity on the anti-virus process in task manager during a profiling run. The anti-virus we are using is Symantec version 9.
Scott.