Community
Participate
Working Groups
CDT 2.0.0.200404190838 Eclipse (200404131323) Test case: 1. Create a standard C++ project, call it StdCpp. 2. Open the project properties and enable the auto scanner discovery. 3. Build StdCpp (the goal is to let the scanner discovery do it's thing). 4. Add a main.cpp file and insert the following code: #include <iostream> ma[^SPC] // ** (A) ** 5. Initiate content assist on line (A) to insert main() routine. RESULT: Content assist times out. This is impractical. For such a small and simple project, I would not expect content assist to be timing out on me.
Like Dave D was saying, I think we should increase the default "time out" period. What happens when you increase the time out? How long does Content Assist take in spitting out iostream stuff?
I had to up the timeout to 6 seconds. For this example, there is no completion list. The only thing that content assist does is insert the main() routine; this is what makes the 6 seconds seem like a waste of time.
Hoda, perhaps upon timeout you can still propose code template proposals? I'll still own the defect for the time being, as I am sure there is some more tuning I can do.
John, Even for templates, we need at least to know our scope. But with null completion node, we do not know anything.
I have committed a fix to HEAD which reduced the parse time of this file from 5.1 seconds to 3.5 seconds. This fix was within the ContextualParser (so from the parse side of things, not from the scanner side of things). I shall keep the defect open to try and see if there's anything I can do from the scanner side of things to speed this up some more (maybe maintaining a cache of files that have been included so that we don't even open the file on things that will #ifndef out?)
There are a number of related defects to parser performance. We'll use this one as the flagship. The issue is not only speed but memory consumption as well. We should set a benchmark which we need to meet to resolve this defect. I will use the following file in my laptop using mingw: #include <windows.h> #include <stdio.h> #include <iostream> Currently I'm getting around 8 seconds. We need to get this down to 2 seconds.
*** Bug 53622 has been marked as a duplicate of this bug. ***
I'll move this to me even though John and Andrew will eventually help me with this. I want to make sure if someone comes hunting that they come get me first :-).
*** Bug 51638 has been marked as a duplicate of this bug. ***
Assigning to 2.0.1
When you take class loading and jitting out of the picture, we are actually getting around 5 secs to parse the trilogy (windows.h/stdio.h/iostream). 2 seconds is probably still our target to get content assist to deal with the results and still fit in the 3 second window.
As a side note, gcc -c main.cpp takes about 2 seconds on my machine. So yes, 2 seconds should be our target. Also note that I'm getting about 1.2 secs with Visual C++ Toolkit (mind you the included files are a little different, but not smaller).
The current state is: 2.0 GA 6000ms 135.7 MB object memory Aug 11 2.0.1 build 3000ms 82.0 MB object memory Note that object memory is Total memory allocated from aprof -- it is not the peak usage. The lower number should reduce the garbage collection penalty (especially during the initial index) Since we are not looking at additional performance improvements in 2.0.1, I am moving this defect to 2.1
Going forward, we'll have to take a different approach. I am currently investigating incremental parsing to cut down on parse times during content assist. This is more likely for 3.0, though.
After using it on simple projects, I conclude that content assist is now practical for simple Hello World examples. The biggest road block will be working with compilation units with lots of tokens. The trilogy (windows, stdio, iostream) I believe is a worst case scenario (180000 tokens). Getting that in 3 seconds on our middle of the road test machine is pretty good. There may be things we can do to cut this down, such as keeping the AST around and only reparsing the lines that change between content assists or rewriting the parser in C. But that would be more of the enhancement request variety and something we may consider in a future release (maybe). For now mission accomplished and congrats to the team (John and Andrew) for getting us there.
