Fee.dll terribly slows down the debugger

[ovz]

Hi All,

My team works on a large code base a significant part of which is in Fortran. We recently upgraded to Intel(R) Visual Fortran Composer XE 2013 Update 3 Integration for Microsoft Visual Studio* 2012, 13.0.3624.11. After this we all are experiencing unbearable slowdowns when debugging the code. Whenever we try to debug Fortran or even just have a Fortran module on the call stack every debugger step through the code takes 10 or more seconds of full CPU load. Using Sysinternals Process Explorer I was able to see the call statck like one listed below. Note FEE.dll which is Intel(R) Fortran Expression Evaluator 13.0.2225.2. 

I need help with this urgently as the entire team cannot work normally because of this. 

msdia110.dll!DllGetClassObject+0x2c060
msdia110.dll!DllGetClassObject+0x2c1ff
msdia110.dll!DllGetClassObject+0x2c278
msdia110.dll!DllGetClassObject+0x2b3b7
msdia110.dll!DllGetClassObject+0x3536e
msdia110.dll!DllGetClassObject+0x1093a
FEE.dll!DllGetClassObject+0x205f7
FEE.dll!DllGetClassObject+0x20972
FEE.dll!DllGetClassObject+0xb18e
FEE.dll!DllGetClassObject+0xb4fe
FEE.dll!DllGetClassObject+0x9cc4
FEE.dll!DllGetClassObject+0x505f
FEE.dll!DllGetClassObject+0x655c
FEE.dll!DllGetClassObject+0x760a
FEE.dll!DllGetClassObject+0x7e14
FEE.dll!DllGetClassObject+0x8354
FEE.dll!DllGetClassObject+0x307e2
VSDebugEng.dll!DkmDllEnsureInitialized+0x8169c
VSDebugEng.dll!ProcDkmFree+0x1989
VSDebugEng.dll!ProcDkmFree+0x1776
VSDebugEng.dll!DkmDllEnsureInitialized+0x857e5
VSDebugEng.dll+0xc25d
VSDebugEng.dll!DkmDllUninitialize+0x24a
ntdll.dll!RtlInitializeExceptionChain+0x85
ntdll.dll!RtlInitializeExceptionChain+0x58

[Bernard]

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

[Tobias_Loew]

@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

[Christian]

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

[FortranFan]

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! :-(

[Bernard]

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

[Georg_Z_Intel]

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

[Christian]

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

[Tobias_Loew]

@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.

[WASHIM_A___Intel_]

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

[Georg_Z_Intel]

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

[Schulz__Michael]

Hello Georg,

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

Regards

[Georg_Z_Intel]

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

[Jörg_S_]

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
 

[Georg_Z_Intel]

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

[Georg_Z_Intel]

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.

[Georg_Z_Intel]

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