Comments
Sort by recent activity
StephenC wrote:
I'm really surprised that the profiler is having anywhere near that sort of impact. With the low impact mode I've never seen it have any sort of signicicant impact.
Did enabling inlining make any difference?
Stephen
Enabling inlining did not have much impact - I'd have to time it to get a better feel, but it wasn't dramatic.
A little background: The application is a specialized document editor, and i'm trying to profile a certain feature that requires an open document, looking specifically at the behavior when I have a large document open. Opening a document does some soundness checks on the document which results in several seconds of CPU-bound execution including millions of function calls on a fairly deep call stack (but only the bottom couple frames of the stack are "in motion").
So, the amount time taken to gather profile data for that path may be reasonable - but at the moment I don't care about it, hence my desire to start profiling later in the applications execution.
Previously, I've profiled this app using the VSTS profiler where I'd generally start with a sampling profile session and then when I've identified an area that needs work, I'd build a special-purpose driver program that would exercise only that area and run that program using the instrumented profiler. It's not ideal, and I'd hoped that ANTS would let me avoid having to build special purpose profiling drivers, but without the ability to start mid-way through a program invocation, I don't see that happening. / comments
StephenC wrote:
I'm really surprised that the profiler is having anywhere near that sort of impact. With the low impact mode I've never seen it have any sort of signicicant impact.
Did enabling i...
AndrewH wrote:
That certainly does sound like an unusually high amount of overhead.
Are you using a virtualized environment? Some VM implementations don't provide a very efficient way of reading the CPU time stamp counter which can have a negative effect on the performance of the profiler. A warning is written to the log file if this is detected.
On XP you should be able to find this in ...
Windows Server 2003 R2 Enterprise Edition SP2, x64, dual-dual-core Xeon w/8GB of RAM. I'm running several VMs on the machine, but they're just idle and not involved.
I did find the log file - no mention of reading the CPU tick counter taking a long time.
Also, are you using .NET 1.1? The profiler API available in that version of .NET is much less efficient than the one introduced into .NET 2.0. For many applications you can work around this by forcing them to run using the .NET 2.0 framework while profiling using an application config file.
.NET 3.5 SP1 (although the program in question is only using .NET 2.0 functionality). / comments
AndrewH wrote:
That certainly does sound like an unusually high amount of overhead.
Are you using a virtualized environment? Some VM implementations don't provide a very efficient way of reading ...
Unfortunately, those tips don't appear to help. I'm already using a less detailed profiling mode.
The timeline is cool, but the impact of the profiler is so profound that getting to the point in my app that I actually want to examine takes 5+ minutes when running under the profiler versus a few seconds when not running under the profiler. That doesn't make for a very pleasant experience.
Using the DLL to raise a named event doesn't sound like it'd help either - I can easily find the time of interest using the timeline - it's the painful process of running the program up to that point that I'm trying to avoid.
I'll keep my fingers crossed for attach to process and/or other ways to turn profiling on/off in future version.
I will try the "enable inlining" option to see if it makes an appreciable difference! / comments
Unfortunately, those tips don't appear to help. I'm already using a less detailed profiling mode.
The timeline is cool, but the impact of the profiler is so profound that getting to the point in m...
Any other suggestions? / comments
Any other suggestions?
StephenC wrote:
Hi,
Are you on a non-English language computer with a non-English installation of Microsoft Visual Studio?
Stephen
No. English all around. / comments
StephenC wrote:
Hi,
Are you on a non-English language computer with a non-English installation of Microsoft Visual Studio?
Stephen
No. English all around.
StephenC wrote:
Hi,
In general the options grey out if the add-in doesn’t understand the project type. I think MVC ASP.NET applications produce this, but things like COM+ apps and services will confuse it as well. (Which in a way is fair enough, as these have to be installed after compiling and ANTS can’t do that for you)
The solution I'm working in now contains 22 projects:
2 .NET EXE projects (one console, one WinForms)
1 VC++ Makefile project (used to automate a bunch of post-build stuff)
19 .NET DLL projects, of which 7 are VSTS unit test projects.
The Makefile project is the Startup Project in the solution.
If I remember, I'll try opening a solution that doesn't have a Makefile project in it to see if that's throwing it off (seems like the most likely candidate). / comments
StephenC wrote:
Hi,
In general the options grey out if the add-in doesn’t understand the project type. I think MVC ASP.NET applications produce this, but things like COM+ apps and services will...
As an alternative, rather than adding an option, simply suppress extended properties from the script fragments in the documentation entirely, or suppress only MS_Description extended properties, as these already appear in the documentation elsewhere and don't add any information for the reader of the document. / comments
As an alternative, rather than adding an option, simply suppress extended properties from the script fragments in the documentation entirely, or suppress only MS_Description extended properties, as...
+1 It would be very handy to have column meta-data for views. / comments
+1 It would be very handy to have column meta-data for views.