Community
Participate
Working Groups
"Open Declaration" (by pressing F3) needs sometimes more tham 30 seconds to open the file. CPU goes during this operation in this cases to 100%. But sometimes the same operation only needs split second. Steps I could perform to reproduce this behaviour: 1. Open cpp File of my project (there semms nothing special to this file) 2 do multiple times the following steps: 2.1. press F3 while cursor is positioned on an symbol (parameter type of an method) 2.2. wait for popup new file with location of the requested declaration 2.3. close file where declaration of requested symbol was found Step 2.2 somtimes needs just a moment (in particular the first 2-5 times after starting eclipse), but mostly 30 seconds or more. There seems no other background processes running during this investigation.
I starting eclipse with -debug and see this output *ca. 30 seconds* after pressing F3: FIRING POST_CHANGE Delta [Thread[main,6,main]]: CMODEL [*]: {CHILDREN | FINE GRAINED} geco-RelWithDebInfo@geco CPROJECT [*]: {CHILDREN | FINE GRAINED} file:/TO OPEN with symbol inside.h WORKING_UNIT [+]: {} Listener #1=org.eclipse.cdt.internal.core.model.PathEntryManager@1bf61549 -> 0ms Listener #2=org.eclipse.cdt.internal.core.index.provider.IndexProviderManager@220c95ab -> 0ms Listener #3=org.eclipse.cdt.internal.core.pdom.CModelListener@68361f03 -> 0ms Listener #4=org.eclipse.cdt.internal.ui.navigator.CNavigatorContentProvider@21ef81ee -> 0ms Listener #5=org.eclipse.cdt.internal.ui.navigator.CNavigatorContentProvider@1fd9df64 -> 0ms Listener #6=org.eclipse.cdt.internal.ui.text.CReconciler$ElementChangedListener@6273ab97 -> 0ms Listener #7=org.eclipse.cdt.internal.ui.text.CReconciler$ElementChangedListener@4b86427c -> 0ms FIRING POST_RECONCILE Delta [Thread[main,6,main]]: <NONE> [1.418.813.541.118] Parse 44: 86ms [1.418.813.541.123] Ambiguity resolution : 4ms CModelBuilder2: parsing file: mode=skip all time=117ms CModelBuilder2: building children=1458 time=22ms FIRING POST_CHANGE Delta [Thread[org.eclipse.cdt.internal.ui.text.CReconciler,1,main]]: <NONE> FIRING POST_RECONCILE Delta [Thread[org.eclipse.cdt.internal.ui.text.CReconciler,1,main]]: file:/TO OPEN with symbol inside.h WORKING_UNIT [+]: {} Listener #1=org.eclipse.cdt.internal.core.model.PathEntryManager@1bf61549 -> 0ms Listener #2=org.eclipse.cdt.internal.core.index.provider.IndexProviderManager@220c95ab -> 0ms Listener #3=org.eclipse.cdt.internal.core.pdom.CModelListener@68361f03 -> 0ms Listener #4=org.eclipse.cdt.internal.ui.navigator.CNavigatorContentProvider@21ef81ee -> 0ms Listener #5=org.eclipse.cdt.internal.ui.navigator.CNavigatorContentProvider@1fd9df64 -> 0ms Listener #6=org.eclipse.cdt.internal.ui.text.CReconciler$ElementChangedListener@6273ab97 -> 0ms Listener #7=org.eclipse.cdt.internal.ui.text.CReconciler$ElementChangedListener@4b86427c -> 0ms Listener #8=org.eclipse.cdt.internal.ui.text.CReconciler$ElementChangedListener@29815e67 -> 0ms [1.418.813.541.757] Parse 45: 62ms [1.418.813.541.761] Ambiguity resolution : 4ms
Created attachment 249495 [details] series of jstacks recorded while pressing F3 and waiting...
After some further investigations I discovered tha turning of CDT Code Analysis will fix this problem. Of course this is not what I would like to do, but it gives a hint where to look at. In my step by step description of this Bug in my original comment the point is the redisplaying of the file in which I pressed F3! In this Moment (redisplay) something is going on and blocks further calls of "Open Declaration" as long as 'something' has finished. I assume that 'something' is cdt internal code analysis. Just switching between 2 differenet files (Editor Tabs) will result in high CPU Load and will block "Open Declaration" for several seconds. Between: The file I talk about (where I press F3) has round about 4000 lines and containes Qt code and the code analyser shows no warning or error in this file (only some TODOs ;))
For file above 4000 lines exists option "C\C++ -> Options -> Scalability". Try disable "Live parsing" options for file with such size.
(In reply to Alexey Alexey from comment #4) > For file above 4000 lines exists option "C\C++ -> Options -> Scalability". > Try disable "Live parsing" options for file with such size. This doesn't make things better. Note that these long 'blocking times' occured not every time. For me it looks like a race condition. Sometimes eclipse hmi blocks and sometimes not. Changing all settings in .metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.cdt.codan.core.prefs from RUN_AS_YOU_TYPE\=>true to RUN_AS_YOU_TYPE\=>false seems to help us out of this but this is not really what we want.
