Comments
Sort by recent activity
Hi Herry,
OK thanks. Sorry it hasn't worked. I do have a suspicion about what's happening though.
Could you do me a favour and do the following please.
- Start ANTS Profiler.
- Hit Cancel on the "Performance Profiler Settings" dialog.
- Go to Tools > Options and uncheck the "Include source code with saved results" option, then hit OK.
- Now click File > New Profiling Session.
- Profile your application.
- Look at some methods with source code and see if the source view displays them correctly.
Can you let me know the results of this please?
Thanks,
Bart / comments
Hi Herry,
OK thanks. Sorry it hasn't worked. I do have a suspicion about what's happening though.
Could you do me a favour and do the following please.
- Start ANTS Profiler.
- Hit Cancel on the "P...
Hi there,
Please see this post for instructions on how to change the font in the source code view: http://www.simple-talk.com/community/bl ... 69800.aspx
If this doesn't fix the problem please let us know.
Many thanks,
Bart / comments
Hi there,
Please see this post for instructions on how to change the font in the source code view:http://www.simple-talk.com/community/bl ... 69800.aspx
If this doesn't fix the problem please let u...
Great, thanks Herry. We'll get a fix out early next week that will allow you to include source with saved results.
Cheers!
Bart / comments
Great, thanks Herry. We'll get a fix out early next week that will allow you to include source with saved results.
Cheers!
Bart
Hi Nick,
I'd say that they've probably been boxed because they've been added to collections, or perhaps they're the values of member fields of classes types, whose instances are going to be on the heap. I think the former is probably more likely.
Now, I've never looked at the memory profiler codebase, so I'm unsure how it deals with arrays of value types, and I've never been looking for them when tracking down a memory problem (I tend to filter out anything I'm not interested in using the column filters), but I seriously doubt the individual values would appear in the results.
Hope that helps.
Thanks,
Bart / comments
Hi Nick,
I'd say that they've probably been boxed because they've been added to collections, or perhaps they're the values of member fields of classes types, whose instances are going to be on the ...
Hi there,
Yeah, the problem here is that profiling is linked to the presence of the original IE instance. If that closes then profiling stops. I suspect we probably just need to decouple these and then you should find it all works (hopefully). Look for this in the next 4.1 early access build, which will likely be available within the next couple of weeks.
In the meantime, please accept my apologies for the problems you're having. We'll get you set up with a new trial period when the fix is available. In the meantime I'd drop back to version 3 when profiling this application--versions 3 and 4 will install happily side by side, although 3 can get upset if you're running 4 at the same time.
I'll let you know when there's anything more.
Thanks,
Bart / comments
Hi there,
Yeah, the problem here is that profiling is linked to the presence of the original IE instance. If that closes then profiling stops. I suspect we probably just need to decouple these and ...
Hi Paul,
Thanks for this! It's great to hear that the product is really helping someone out.
Cheers,
Bart / comments
Hi Paul,
Thanks for this! It's great to hear that the product is really helping someone out.
Cheers,
Bart
James, FYI: http://www.red-gate.com/MessageBoard/vi ... php?t=7592 / comments
James, FYI:http://www.red-gate.com/MessageBoard/vi ... php?t=7592
Hi Scott,
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 / comments
Hi Scott,
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 i...
Hi Scott,
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. [image]
Thanks,
Bart / comments
Hi Scott,
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 do...
OK, thanks for letting me know Scott. / comments
OK, thanks for letting me know Scott.