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

[SergeyKostrov]

>>...The problem is mostly related to what you wrote in qouted sentences... There is a difference between your '...mostly related...' and my '...there is just one possibility...' because this is just one still Not proven possibility. So, let's wait for a response from Ovz or Intel software engineers who will look into the problem.

[Bernard]

Yes agree with you that we should wait for response.

[Anonymous66]

One of my colleagues who specializes in debugging is working on this issue in premier support.

Annalee

[ovz]

I've uploaded the source code project and build instructions to Premier tech support. Waiting for response.

[AK]

We have the same issue in our mixed C++/Fortran application. Installed Composer Update 4, but the problem persists.

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.

Any suggestions on fixes or workarounds for this is very much appreciated.

[jimdempseyatthecove]

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

Do you have a lot of variables in your Watch window(s)?
If so, what happens if you remove all of them? (then set the ones you really need)

Do you have any conditional breaks set?
if so, what happens if you remove (all of) them?

One more stab in the dark, try turning off intelisense (thing that shows contets of variable when hovering mouse over a variable).

Jim Dempsey

[Steven_L_Intel1]

fee.dll is the Fortran debug expression evaluator. The indications here are that it is calling back into Visual Studio to look up names. We don't typically see a lot of overhead from this.

It looks to me as if you are getting appropriate assistance through Premier Support issue 696480.

[AK]

Thank you for the hints, but no luck..

jimdempseyatthecove wrote:

Do you have a lot of variables in your Watch window(s)?

If so, what happens if you remove all of them? (then set the ones you really need)

Nothing in the Watch window (or Memory), still slow.

jimdempseyatthecove wrote:

Do you have any conditional breaks set?

None

jimdempseyatthecove wrote:

One more stab in the dark, try turning off intelisense (thing that shows contets of variable when hovering mouse over a variable).

No effect..

[SergeyKostrov]

This is almost one month old problem and my new question is: Is it an UI problem or something else? So, in order to verify if it is some UI issue try to compare what Windows messages are received in your "Slow-To-Debug" project vs. a simple "Fast-To-Debug" project ( let me call it so ) with a Microsoft's utility Spy++. The utility should be located at: [ VSInstallDir ]\Common7\Tools Name of the executable is: Spyxx.exe

[Bernard]

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

[AK]

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

[AK]

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.

[Bernard]

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

[SergeyKostrov]

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

[Bernard]

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

[Steven_L_Intel1]

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

[Tobias_Loew]

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

[Bernard]

Thanks for updating.

[Steven_L_Intel1]

Well, that disables the Fortran debug expression evaluator.

[Tobias_Loew]

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

[Georg_Z_Intel]

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