Fee.dll terribly slows down the debugger

82 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

Hello,

we are stumbled about the same problem today with VS2013 and Intel fortran composer up to Version 2016.0.110

Is there any progress visible?
Our solution until today is compiling using Visual Studio 2013 and debugging in Visual Studio 2010.

Best regards,
Jörg Sichermann
 

Hello,

unfortunately I forgot to update this thread. We've had numerous request about this issue and seem to have missed this one.

With Intel® Parallel Studio XE 2016 Composer Edition (initial release) it should have been "fixed". It's rather a workaround than a real fix because we still have the dependency on the VS API as mentioned earlier. The change is described here:

https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2016-composer-edition-fortran-debug-solutions-release-notes
(section Fortran Expression Evaluator (FEE) for debugging Fortran applications with Microsoft Visual Studio*, Known Issues and Limitations, FEE Truncates Entries in Locals Window)

The workaround is to set an upper threshold for the number of locals to display and evaluate. By default it's 500 but can be changed by setting the environment variable FEE_MAX_LOCALS.

If you still experience a (significant) slowdown, please set FEE_MAX_LOCALS to a value below 500 (or 0 for no locals; -1 for unlimited). You need to set that variable so that VS can get it (e.g. system wide) and also restart VS in order to take effect.

Please let me know whether this helps.

Best regards,

Georg Zitzlsberger

Hello Georg Zitzlsberger,

thank you very much for your answer. I tryed your suggestion. So I installed the trial of Intel Parallel Studio XE 2016 Update 1 composer edition fortran. I checked "Use Managed Compatibility Mode". I checked FEE_MAX_LOCALS=30 is set. And this did not work for me. 

I saw some speedup, but the delay is still too long. It is about 3s-10s per step.

Using Microsoft Visual Studio 2010 in conjunction with Intel Visual Fortran Composer 2013 Update 3 there is no noticable delay.

Best regards,
Jörg Sichermann

Hello,

seems like this is another problem.

First of all, if you've set FEE_MAX_LOCALS=0 you should not see any locals* at all. If this is the case and stepping speed is still slow, please try the following:

  1. Close all windows (except the source window). Also close the tool bar "Debug Location" which displays the stack frame and hence also needs data from the debug engine.
  2. If there is noting to display for the debugger, except for the location pointer in the source window, then stepping should be fast.
  • If it's not then I'd need a test sample derived from your application that shows the same behavior. This is not simple, unfortunately, but we won't be able to locate the culprit otherwise.
  • If stepping is fast, then open one window at a time and check the stepping speed. You might see a gradual increase of the stepping time with every window which is kind of expected - the more data to fetch, the higher the run control latency. But if you identify a window that massively (and unexpectedly) adds the latency we could look into that. Again, we'd need a test case for this.

Could you please try the above steps?

Thank you & best regards,

Georg Zitzlsberger

*: In the past, the locals window was identified to contribute most to the stepping latency because most Fortran programs use massive amounts of locals and the debugger has to evaluate all of them. With the API change from VS discussed earlier in this thread, it's not possible to interrupt this evaluation anymore and hence we've implemented an upper bound of locals as a mitigation.

Hello Georg Zitzlsberger,

thank you for your suggested Solution. Lack of time I need to move testing. I'll get back to you as soon as I tried your suggestion. 

At the moment we use VS2010 SP1 for debugging and VS2013 for compiling. This combination works fine.

Best regards,
Jörg Sichermann

Hello Georg Zitzelsberger,

I have recently tested your suggestion. There is no acceleration. Debugging in VS2013 is terribly slow with FEE_MAX_LOCALS = 0. In this case, all the windows were closed except for the editor window. So I decided to use VS2010 for debugging and coding of Fortran.

Best regards,
Jörg Sichermann

Hello,

do you have conditional breakpoints set? I guess not but need to have this clarified too.

What would help us is a "small" test case. Given the previous cases wrt. FEE performance that might not be simple. However, I'd be glad if you could at least try it and share it with us.

In the meantime I'll discuss other options with our engineers.

Thank you & a happy new year!

Georg Zitzlsberger

Pages

Leave a Comment

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