Bug 61675 - [Parser] 100% CPU loading and high latency of interaction in the time of parsing c code
Summary: [Parser] 100% CPU loading and high latency of interaction in the time of pars...
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-parser (show other bugs)
Version: 2.0   Edit
Hardware: PC Linux
: P2 major (vote)
Target Milestone: 2.0.1   Edit
Assignee: John Camelon CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 62251
Blocks:
  Show dependency tree
 
Reported: 2004-05-10 19:53 EDT by Dmitry B. Khlonin CLA
Modified: 2004-08-13 15:43 EDT (History)
2 users (show)

See Also:


Attachments
~/workspace/.metadata/.plugins/org.eclipse.cdt.core/.log (52.94 KB, application/octet-stream)
2004-05-10 19:55 EDT, Dmitry B. Khlonin CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry B. Khlonin CLA 2004-05-10 19:53:27 EDT
There are some problems with working with CDT in Eclipse:
1) C code parser working with unacceptable priority and increasing latency of
interaction with editor when opening new file and trying to scroll or edit it
2) Disabled caching of already parsed files then parsing takes some time in
every opening of file
3) Some erorrs in parsing of syntaxically correct files (File with parser log is
attached)
4) Growing memory consumage and consequent fatal errors

I have Eclipse CDT 2.0M8

P.S. If necessary I can contribute to your project. I have high skills in Java,
Eclipse and highly motivated to have uniplatform C/C++ IDE.
Comment 1 Dmitry B. Khlonin CLA 2004-05-10 19:55:38 EDT
Created attachment 10478 [details]
~/workspace/.metadata/.plugins/org.eclipse.cdt.core/.log
Comment 2 John Camelon CLA 2004-05-10 20:17:55 EDT
1.  What are your preferences for the C++ editor?  Are you asking the CModel 
builder to follow includes?  The default is off for a reason (performance).  
If you are not following includes and you find that latency increases as you 
scroll, please attach a sample that does so.  

2.  We do wish to cache the inclusions : it requires our entire framework to 
be persistable, in order to scale for large workspaces.  This is a challenge 
that is not in the 2.0 timeframe unfortunately.  

3.  The parser log attached indicates only preprocessor errors.  Do you have 
your include paths set up properly?  What compiler are you using?  Are you 
using Standard or Managed Make?  

4.  Memory consumption is a concern and I am attempting to address it in order 
to address scalability in the 2.0 timeframe.  Off the record, M8 is a pretty 
bad build for memory usage (both the Eclipse Platform and the CDT).  

If you are interested in contributing to the discussion of how we can make our 
parser framework scale and perform, subscribe to the CC of defect 57816 and 
give your 2 cents.  If you are interested in contributing code, even better.
Comment 3 Dmitry B. Khlonin CLA 2004-05-14 04:49:56 EDT
>1.  What are your preferences for the C++ editor?  Are you asking the CModel 
>builder to follow includes?  The default is off for a reason (performance).  
>If you are not following includes and you find that latency increases as you 
>scroll, please attach a sample that does so.  

There are only two options in Preferences for this:
a) Search current file and included files, and
b) Search current project

I choosed second one, but nothing changed

>3.  The parser log attached indicates only preprocessor errors.  Do you have 
>your include paths set up properly?  What compiler are you using?  Are you 
>using Standard or Managed Make?  
I trying to resolve source of this problem. gcc. Standard Make
Comment 4 John Camelon CLA 2004-05-26 15:08:07 EDT
Dmitry, when our M9 becomes available please give it a try and let us know if 
things work better for you.  The type-cache that was continually parsing the 
working copy has been tamed to not do so.  

I also would recommend using the scanner discovery feature that allows for 
Standard Make projects to have their include paths imported into the project 
properties so to better aid the parser.  
Comment 5 John Camelon CLA 2004-06-02 14:33:32 EDT
Dmitry, CDT M9 is now available.  Give it a whirl and let us know the status 
of this problem.  
Thanks.
Comment 6 David Daoust CLA 2004-06-21 13:54:44 EDT
Moving this to 2.0.1.   We are defering parser related performance issues to 
2.0.1.   Some of this defect is likely associated with 59468, which is 
the "magic Parser performance" defect.
Comment 7 John Camelon CLA 2004-08-13 15:43:09 EDT
I believe this should be fixed.  Dmitry, please re-open the defect if you can 
reproduce the problem using a CDT 2.0.1 loadbuild.