Fee.dll terribly slows down the debugger

75 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

>>>Using xperf, I found that FEE.dll uses a lot of CPU (~95%) calling into MSDIA110.dll!CDiaEnumTraversal, which again spends a lot of time in MSDIA110.dll!NameMatcher::match.>>>

Why decision to use Xperf on stalled thread.Usually when narrowing the problem down to some routine(s) next step could be single stepping through the code combined with execution tracing and the worst thing trying to understand the problem at assembly code level.

Quote:

iliyapolak wrote:

Why decision to use Xperf on stalled thread.Usually when narrowing the problem down to some routine(s) next step could be single stepping through the code combined with execution tracing and the worst thing trying to understand the problem at assembly code level.

I'm sorry, but you seem to misunderstand the issue here. I try to single step, in Visual Studio, from my C++ code to my Fortran code. Visual Studio stalls for more than 1 minute before hitting the breakpoint in the Fortran code, where almost all the time is spent in FEE.dll (according to xperf).

Quote:

Sergey Kostrov wrote:

Is it an UI problem or something else?

Unfortunately, it does not seem to be an UI problem. The messages logged with Spy++ are the same for fast-to-debug and a slow-to-debug programs.

No I understand your problem pretty well.The sentence related to single stepping is about  attaching external debugger to stalled VS debugger thread.

>>...Unfortunately, it does not seem to be an UI problem. The messages logged with Spy++ are the same for fast-to-debug and
>>a slow-to-debug programs...

Thanks for the verification. Could you post Spy++ logs for both cases, please? Just for review.

>>>No I understand your problem pretty well.The sentence related to single stepping is about  attaching external debugger to stalled VS debugger thread.>>>

It should be done either by Intel devs or by MS escalation engineers.

This issue is being handled by Intel engineering through Intel Premier Support.

Steve - Intel Developer Support

Hi,

I just came across this thread since I'm having the same problem, cf. http://software.intel.com/de-de/forums/topic/392877 . I've got also a premier support thread running and found out that renamig

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Packages\Debugger\FEE.vsdconfig

solves the performance issues. The drawback seems to be that the C/C++ expression-evaluator "knows" only uppercase variable and the C/C++ style arrays and struct. But at least you can debug the program again...

regards

Tobias

Thanks for updating.

Well, that disables the Fortran debug expression evaluator.

Steve - Intel Developer Support

@Steve: in my case after disabling the FEE I regain debugging speed immediately. This highly indicates a performance bug in the FEE.dll as already indicated in this thread.

Hello,

we've worked on the FEE performance issues recently. The coming days we'll make Intel(R) Composer XE 2013 SP1 Update 1 available. This version has FEE performance improvements already.
Please, give it a try and let me know about your experience.

For the case there are still issues, please provide me an example that shows the problems. According to engineering all known performance issues are fixed with Update 1.

Thank you & best regards,

Georg Zitzlsberger

It proves that profiling tools like Xperf are sometimes needed to gain insight into misbehaving application.

@Georg Zitzlsberger: I was looking forward to SP 1/Update 1 but there was just a small speed enhancement: debugging Fortran code with VS 2012 is still awfully slow (of course, it is fast if you build a small test project with a handful of variables - but real world application can have hundreds of projects, mixed languages and thousands of global variables in COMMON-blocks).

If all the performance issues in FEE.dll are fixed, then you may should check all the interfaces to the debugging windows in visual-studio (populating the "locals"-window with ~2000 variables takes ~15 seconds on an Core i7 --- IMHO this behaviour has to be labeled "broken")

Is Intel going to do something about this?

regards

Tobias

Hi! Just installed Intel Fortran ComposerXE 2013 SP1 Update 2 - and still no improvement!

We have to use Visual Studio 2012 to compile and Visual Studio 2010 to debug because every single step in VS2012 takes 10-15 seconds (most of the code is in C but there are lots of Fortran files, too).

Anyone at Intel looking at it?

Regards,

Christian

Quote:

Christian wrote:

...

We have to use Visual Studio 2012 to compile and Visual Studio 2010 to debug because every single step in VS2012 takes 10-15 seconds (most of the code is in C but there are lots of Fortran files, too).

Anyone at Intel looking at it?

Regards,

Christian

I've the same problem and so do others who may not even be using Intel Fortran - see links here and there.

I do the same i.e., "use Visual Studio 2012 to compile and Visual Studio 2010 to debug "

My impression is the problem is deeply rooted in Microsoft's base Visual Studio 2012 (and 2013) product and Intel can do little about it.  The issue seems to exacerbate with mixed-language and mixed mode (managed and unmanaged) applications.  As I said above, I've found it to exist even in non-Fortran (e.g., VBA with C/C++) applications.

As I've mentioned elsewhere, Microsoft regressed terribly with their Visual Studio product starting with 2012 on traditional Windows-based programming needs when they were trying to add cool new features for touch-screen, mobile device, Web/ASP.NET programming, etc.  My current plan is to have Visual Studio 2010 around, for a long time, probably! :-(

Btw I am also using VS 2013 for programming and VS 2010 for debugging.

Hello,

Because of recently increased interest, I'd like to inform you about the current status.

Our debugger engineers have been informed about those performance problems by end of last year (2013). They unfortunately don't seem to find a way to solve this problem because it seems like a change with VS2012 and later introduced that bad performance, as also pointed out above.

For VS2012, could you please install Update 3 or later. According to Microsoft*, there should be an improvement visible:
http://connect.microsoft.com/VisualStudio/feedback/details/774026/debugger-hangs-in-managed-code-in-mixed-mode-c-app

If it does not work with the latest update version of VS2012, please let me know. For VS2013 I do not find any statement whether the improvement from VS2012 is also available there.

Best regards,

Georg Zitzlsberger

Hello Georg,

thank you for your answer.

We are working with VS2012 Update 4 and VS2013 - the performance lack is still there (no improvement at all).

Best regards,

Christian

@Georg: Unfortunately, neither update 3 nor update 4 (which came out since Nov. 2013) for VS2012 provided any speed enhancement for mixed C++/FORTRAN debugging. So disabling FEE.dll is still the only option getting things done in time.

 

Quote:

Christian wrote:

Hello Georg,

thank you for your answer.

We are working with VS2012 Update 4 and VS2013 - the performance lack is still there (no improvement at all).

Best regards,

Christian

Hello,

I'd like to provide you a preliminary last update on the reported performance issues of FEE with VS 2012 and later.

We had some internal discussions about this and our engineers were analyzing different solutions with no positive effect. We regard the latest changes of the APIs with VS IDE (2012 and later) as the main problem. As described in the above post, we cannot circumvent this.

Hence, we won't be able to provide you an update on that. We have to obey to the existing VS IDE APIs and don't see any chance of having this improved in short/mid term.

Regardless of the unavoidable performance concerns with the latest VS IDEs, I hope you still find FEE a useful extension.

Best regards,

Georg Zitzlsberger

Hello Georg,

We are stumbled about the same problem today with VS2012 Update 4. Is this issue solved for Intel 2015?

Regards

Hello,

I've checked the status with engineering and it is still escalated. No progress so far for 2015. I've brought this topic up to engineering again to stress the importance.

Best regards,

Georg Zitzlsberger

Pages

Leave a Comment

Please sign in to add a comment. Not a member? Join today