Home » Language IDEs » C / C++ IDE (CDT) » Task Tags support
| Task Tags support [message #111611] |
Tue, 20 July 2004 09:02  |
Eclipse User |
|
|
|
Originally posted by: katokop1.yahoo.com
What is the status on adding Task Tags support back into the CDT? This
is one of the more useful small features, to my mind, and between this
and the utterly non-functional Code Assist in C mode (on all projects
I've tried other than brand new, one or two-file tests, Code Assist
returns no results under any circumstances even with time out set
extremely high), I'm feeling some pressure to just revert back to Visual
Studio for the time being.
In all, I'm very impressed by the improvements to the CDT, but it feels
like it's missing a few show stopper pieces for a 2.0 release.
Respectfully,
Jonathan Ragan-Kelley
|
|
|
| Re: Task Tags support [message #111943 is a reply to message #111611] |
Tue, 20 July 2004 13:39  |
 John Camelon
Messages: 242
Registered: July 2009 |
Senior Member |
|
|
Task Tags support has unfortunately been deferred until after 2.0.1.
If you are willing to step us through your problems with Content Assist, we
will do our best to address the problems.
Our feedback up to this point has not been that it does not work, just that
it does not perform well enough.
JohnC
"Jonathan Ragan-Kelley" <katokop1@yahoo.com> wrote in message
news:cdimvm$8sl$1@eclipse.org...
> What is the status on adding Task Tags support back into the CDT? This
> is one of the more useful small features, to my mind, and between this
> and the utterly non-functional Code Assist in C mode (on all projects
> I've tried other than brand new, one or two-file tests, Code Assist
> returns no results under any circumstances even with time out set
> extremely high), I'm feeling some pressure to just revert back to Visual
> Studio for the time being.
>
> In all, I'm very impressed by the improvements to the CDT, but it feels
> like it's missing a few show stopper pieces for a 2.0 release.
>
> Respectfully,
> Jonathan Ragan-Kelley
|
|
|
| Re: Task Tags support [message #111970 is a reply to message #111943] |
Tue, 20 July 2004 22:00 |
| Eclipse User |
|
|
|
Originally posted by: katokop1.yahoo.com
The problem seems to be exactly what others experience, only to a very
extreme degree. Content Assist times out (and reports as such in the
status bar), no matter how high I set the timeout length (I've gone up
to 15 or 20 seconds, which just manages to mostly stall the GUI for that
long and then time out, anyway). This happens in all projects which
have much of anything #included. Most of the work I'm doing is in C++
and much of it includes GL, the NVIDIA Cg and CgGL APIs, and some amount
of STL.
I found that an initial dummy project (just a single basic GL+GLUT
application which does nothing) of a file or two could use Content
Assist with reasonable success, but over time, it seems, even that lost
control of its index and began timing out most of the time. This is on
a P4 2.6 with 1gb of RAM, a relatively fast 7200rpm disk, and the latest
Java 1.5 SDK beta. It should not be a matter of system performance.
The problem may be related to the indexing parser having rather large
numbers of warnings and problems in much of my code, but most of it is
relatively straightforward and I cannot tell why, exactly, these
"problems" persist for the indexer's parser. GCC, Intel C++, and VC6,
7, and 2003 all compile all of this code with little or no trouble, and
I generally try to address any warnings returned by -Wall. But even so,
Content Assist doesn't fail to find anything because it hasn't parsed
out any symbols successfully due to parse errors -- it fails because it
times out. And the time-outs happen even in projects and regions of the
code with few or no indexer warnings of any kind.
The bizarre and frustrating part of it all is that the namespace browser
or whatever it's called (pop-up view which allows incremental searching
of all classes, objects, methods, and whatnot in the current workspace
or project) is blazingly fast. I know there is more contextual
information to be processed to make an contextually accurate Content
Assist function, but at the very least it seems a minor filtered tweak
on this list should be possible with a bare minimum of contextual
parsing. I don't mean to second guess your development decisions or
anything, it's just that *something* moderately functional would really
be much better than nothing. Indeed, the dead-simple reverse-search for
like strings that less language-aware text editors (Emacs, SubEthaEdit,
everything) use for totally generic "auto-complete" alone is vastly more
useful than nothing at all (or, in fact, the 2 second stall-then-timeout
that we actually have now), and I expect the fast incremental search
browser I mentioned above is substantially more capable than a brain
dead reverse-search approach.
Anyway, I do greatly appreciate all your work, I'm just frustrated to
perpetually feel like the CDT is just inches away from where I need it
to be in order to be fully productive.
I would gladly test any 3.0.1 beta code which is working on this
problem, and also might consider trying to add initial task list parsing
into the current work, if either seems worthwhile at this point.
Thank you very much.
-jrk
johnc wrote:
> Task Tags support has unfortunately been deferred until after 2.0.1.
>
> If you are willing to step us through your problems with Content Assist, we
> will do our best to address the problems.
> Our feedback up to this point has not been that it does not work, just that
> it does not perform well enough.
>
> JohnC
|
|
|
| Re: Task Tags support [message #112053 is a reply to message #111970] |
Wed, 21 July 2004 14:47 |
John Camelon
Messages: 242
Registered: July 2009 |
Senior Member |
|
|
I would suggest, as an experiment, that you should disable the indexer for
each of your projects, just to see if it is the indexer which is starving
out the UI thread.
Unless you are including 100's of files, we should not encountered parse
times > a few seconds.
Feel free to email me offline to talk about the Task Tag parsing feature:
jcamelon@ca.ibm.com.
Thanks
JohnC
"Jonathan Ragan-Kelley" <katokop1@yahoo.com> wrote in message
news:cdk4ju$uhr$1@eclipse.org...
> The problem seems to be exactly what others experience, only to a very
> extreme degree. Content Assist times out (and reports as such in the
> status bar), no matter how high I set the timeout length (I've gone up
> to 15 or 20 seconds, which just manages to mostly stall the GUI for that
> long and then time out, anyway). This happens in all projects which
> have much of anything #included. Most of the work I'm doing is in C++
> and much of it includes GL, the NVIDIA Cg and CgGL APIs, and some amount
> of STL.
>
> I found that an initial dummy project (just a single basic GL+GLUT
> application which does nothing) of a file or two could use Content
> Assist with reasonable success, but over time, it seems, even that lost
> control of its index and began timing out most of the time. This is on
> a P4 2.6 with 1gb of RAM, a relatively fast 7200rpm disk, and the latest
> Java 1.5 SDK beta. It should not be a matter of system performance.
>
> The problem may be related to the indexing parser having rather large
> numbers of warnings and problems in much of my code, but most of it is
> relatively straightforward and I cannot tell why, exactly, these
> "problems" persist for the indexer's parser. GCC, Intel C++, and VC6,
> 7, and 2003 all compile all of this code with little or no trouble, and
> I generally try to address any warnings returned by -Wall. But even so,
> Content Assist doesn't fail to find anything because it hasn't parsed
> out any symbols successfully due to parse errors -- it fails because it
> times out. And the time-outs happen even in projects and regions of the
> code with few or no indexer warnings of any kind.
>
> The bizarre and frustrating part of it all is that the namespace browser
> or whatever it's called (pop-up view which allows incremental searching
> of all classes, objects, methods, and whatnot in the current workspace
> or project) is blazingly fast. I know there is more contextual
> information to be processed to make an contextually accurate Content
> Assist function, but at the very least it seems a minor filtered tweak
> on this list should be possible with a bare minimum of contextual
> parsing. I don't mean to second guess your development decisions or
> anything, it's just that *something* moderately functional would really
> be much better than nothing. Indeed, the dead-simple reverse-search for
> like strings that less language-aware text editors (Emacs, SubEthaEdit,
> everything) use for totally generic "auto-complete" alone is vastly more
> useful than nothing at all (or, in fact, the 2 second stall-then-timeout
> that we actually have now), and I expect the fast incremental search
> browser I mentioned above is substantially more capable than a brain
> dead reverse-search approach.
>
> Anyway, I do greatly appreciate all your work, I'm just frustrated to
> perpetually feel like the CDT is just inches away from where I need it
> to be in order to be fully productive.
>
> I would gladly test any 3.0.1 beta code which is working on this
> problem, and also might consider trying to add initial task list parsing
> into the current work, if either seems worthwhile at this point.
>
> Thank you very much.
> -jrk
>
> johnc wrote:
>
> > Task Tags support has unfortunately been deferred until after 2.0.1.
> >
> > If you are willing to step us through your problems with Content Assist,
we
> > will do our best to address the problems.
> > Our feedback up to this point has not been that it does not work, just
that
> > it does not perform well enough.
> >
> > JohnC
|
|
|
| Re: Task Tags support [message #112090 is a reply to message #112053] |
Thu, 22 July 2004 00:17 |
| Eclipse User |
|
|
|
Originally posted by: katokop1.yahoo.com
Well I've done some experimentation. First of all, I'm running the
Eclipse 3.0 final with CDT 2.0 final on the latest Sun JDK 1.5.0 beta
under Windows XP (fully patched), using the latest Cygwin toolchain.
All these tests are performed with the C++ indexer *disabled* for the
given project.
Beginning with a large C++ project on which I'm working, I found that
disabling indexing certainly did seem to help. I disabled the indexer
completely, configured the Content Assist timeout to 20 secs, and
restarted Eclipse. Under these conditions, with both Content Assist
source settings (file+includes or current project) I consistently see
lags of 6.5-7.5 seconds. Under an existing managed make test project
consisting of a single plain C file which includes <GL/glut.h> and
optionally string.h or a few other std-c headers, Content Assist makes
suggestions in about 1.5 seconds. However, as soon as any C++ headers
are added to the mix (I tried <string> and <vector> independently) the
time to completion immediately jumps to almost exactly the 6.5-7.5
seconds seen on my larger C++ project.
Out of curiosity, I used GCC's -M flag to evaluate the full include
dependencies of the larger project (included at the end of this
message), and while the project is relatively large, because of making
some minor use of STL, it indirectly includes 150(!) files. For
comparison, the single-file project just including <string> includes
about 70 headers. Both yield identical performance. Also of note is
the fact that I get identical performance in both scenarios (large
project with C++ includes or single-file project with C++ includes),
whether I set the Content Assist scope to the current project or to the
current file and all its includes.
I ran into my older problem of having code assist simply fail to find
any completions when I created an empty managed-make C++ project
containing only the following. In this case, only generic symbols could
be discovered (e.g. "this", but never any local identifiers).
class MyClass {
public:
MyClass() {
// no completions available for any of these -- uncomment and try
//pu
//pri
//pro
//this->
//metho
//this->metho
}
~MyClass();
int method();
int pub;
protected:
int prot;
private:
int priv;
};
Also, while for some reason my more complex projects do tend to return
some results after 6.5-7.5 seconds, I consistently observe two
significant errors in functionality:
I observe a frustrating behavior where much of the time, the content
assist drop-down disappears just as soon as it appears. This seems to
happen in multiple contexts, and with multiple types of invocation
(automatic invocation after a '.' or '->' operator, pressing ctrl+space
mid-way through typing an identifier, or pressing ctrl+space immediately
after an opening '<' in a template object declaration [e.g. 'vector<'
then ctrl+space]). This happens almost completely consistently the
first time a content assist is requested, and occasionally the second
time this same request is made in direct succession, but it tends to
stay open after several successive tried. This happens whether or not
any other direct UI events are going off (it often happens even with the
keyboard inactive, the mouse totally still, and window manager focus on
the Eclipse editor region currently being used).
Secondly, there seems to be a problem with namespace traversal using the
'::' operator. Trying to traverse through the std namespace this way
reveals substantial problems. std:: pauses then returns nothing.
Subsequently pressing ctrl-space returns a seemingly correct list of
options, and typing filters these options (as expected). But then, for
example, typing std::vector:: + ctrl-space pauses for the usual 6-7
seconds then returns only one option: "vector". Traversing this way
leads to an infinite series of std::vector::vector::vector... types as
the only option in the namespace. Clearly not what is expected. And
std::string:: + ctrl-space reveals no options (it doesn't time out, it
pauses for a number of seconds and then resumes with no time out
warning), whereas std::string-> appears to expose nearly everything in
the local namespace (objects and types in *my* project). Altogether
strange. Indeed, I am now noticing that just ;\n -> + ctrl-space
exhibits similar behavior.
I'm sorry to lump so many issues together, but as I said at first,
Content Assist seems generally problematic. The performance issue is
critical, but the functionality seems to exhibit other issues, as well.
The clear and present conclusion which can be drawn from this, however,
is that the main problems with Content Assist exist only in C++ land.
Pure C fares quite well -- 1.5 second Assist lags for extremely simple
files seem rather poky, but it generally works. Once C++ is introduced,
the problems begin appearing. There are issues with general C++
functionality, but above all, the current design clearly just cannot
handle the complex include structure of the std-c++ libraries, or
anything of the sort.
I'm sure you all are seriously thinking about how this should be
addressed, but it seems the assistant's search process should have the
least trouble with exactly these libraries which throw it off the most
today, since it can reasonably invest substantial resources in indexing
and optimizing these paths, and since they are heavily included, their
indices should generally remain cached from first use throughout a
user's work on a project.
I hope this helps at least somewhat. Below I've included the full
indirect includes of the file on which I first observed this trouble.
-jrk
-- Large C++ Project ---------------------------------------------------
g++ -M sdanalysis.cpp -I<all-necessary-include-paths> gives the following:
sdanalysis.o: sdanalysis.cpp ../libaqsistypes/aqsis.h \
.../libaqsistypes/config.h /usr/include/assert.h /usr/include/_ansi.h \
/usr/include/newlib.h /usr/include/sys/config.h \
/usr/include/machine/ieeefp.h /usr/include/cygwin/config.h \
.../libaqsistypes/aqsis_types.h ../libaqsistypes/posix/aqsis_compiler.h \
/usr/include/c++/3.3.1/sstream /usr/include/c++/3.3.1/istream \
/usr/include/c++/3.3.1/ios /usr/include/c++/3.3.1/iosfwd \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/c++config.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/os_defines.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/c++locale.h \
/usr/include/c++/3.3.1/clocale /usr/include/locale.h \
/usr/include/c++/3.3.1/cctype /usr/include/ctype.h \
/usr/include/c++/3.3.1/bits/stringfwd.h \
/usr/include/c++/3.3.1/bits/fpos.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/c++io.h \
/usr/include/c++/3.3.1/cstdio /usr/include/c++/3.3.1/cstddef \
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/stddef.h \
/usr/include/stdio.h \
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/stdarg.h \
/usr/include/sys/reent.h /usr/include/sys/_types.h \
/usr/include/sys/types.h /usr/include/machine/types.h \
/usr/include/sys/features.h /usr/include/cygwin/types.h \
/usr/include/sys/sysmacros.h /usr/include/stdint.h \
/usr/include/sys/stdio.h /usr/include/sys/lock.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/gthr.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/gthr-default.h \
/usr/include/pthread.h /usr/include/signal.h /usr/include/sys/signal.h \
/usr/include/cygwin/signal.h /usr/include/sched.h /usr/include/time.h \
/usr/include/machine/time.h /usr/include/unistd.h \
/usr/include/sys/unistd.h /usr/include/getopt.h \
/usr/include/c++/3.3.1/cwchar /usr/include/c++/3.3.1/ctime \
/usr/include/wchar.h /usr/include/c++/3.3.1/bits/functexcept.h \
/usr/include/c++/3.3.1/exception_defines.h \
/usr/include/c++/3.3.1/exception \
/usr/include/c++/3.3.1/bits/char_traits.h \
/usr/include/c++/3.3.1/cstring /usr/include/string.h \
/usr/include/c++/3.3.1/bits/localefwd.h \
/usr/include/c++/3.3.1/bits/ios_base.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/atomicity.h \
/usr/include/c++/3.3.1/bits/locale_classes.h \
/usr/include/c++/3.3.1/string /usr/include/c++/3.3.1/memory \
/usr/include/c++/3.3.1/bits/stl_algobase.h \
/usr/include/c++/3.3.1/climits \
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/limits.h \
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/syslimits.h \
/usr/include/limits.h /usr/include/c++/3.3.1/cstdlib \
/usr/include/stdlib.h /usr/include/machine/stdlib.h \
/usr/include/alloca.h /usr/include/c++/3.3.1/new \
/usr/include/c++/3.3.1/bits/stl_pair.h \
/usr/include/c++/3.3.1/bits/type_traits.h \
/usr/include/c++/3.3.1/bits/stl_iterator_base_types.h \
/usr/include/c++/3.3.1/bits/stl_iterator_base_funcs.h \
/usr/include/c++/3.3.1/bits/concept_check.h \
/usr/include/c++/3.3.1/bits/stl_iterator.h \
/usr/include/c++/3.3.1/bits/stl_alloc.h \
/usr/include/c++/3.3.1/bits/stl_threads.h \
/usr/include/c++/3.3.1/bits/stl_construct.h \
/usr/include/c++/3.3.1/bits/stl_uninitialized.h \
/usr/include/c++/3.3.1/bits/stl_raw_storage_iter.h \
/usr/include/c++/3.3.1/bits/stl_function.h \
/usr/include/c++/3.3.1/bits/basic_string.h \
/usr/include/c++/3.3.1/algorithm \
/usr/include/c++/3.3.1/bits/stl_algo.h \
/usr/include/c++/3.3.1/bits/stl_heap.h \
/usr/include/c++/3.3.1/bits/stl_tempbuf.h \
/usr/include/c++/3.3.1/bits/basic_string.tcc \
/usr/include/c++/3.3.1/streambuf \
/usr/include/c++/3.3.1/bits/streambuf.tcc \
/usr/include/c++/3.3.1/bits/basic_ios.h \
/usr/include/c++/3.3.1/bits/streambuf_iterator.h \
/usr/include/c++/3.3.1/bits/locale_facets.h \
/usr/include/c++/3.3.1/cwctype /usr/include/wctype.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/ctype_base.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/ctype_inline.h \
/usr/include/c++/3.3.1/bits/codecvt.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/time_members.h \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/messages_members. h \
/usr/include/c++/3.3.1/bits/basic_ios.tcc \
/usr/include/c++/3.3.1/limits \
/usr/include/c++/3.3.1/bits/istream.tcc /usr/include/c++/3.3.1/locale \
/usr/include/c++/3.3.1/bits/locale_facets.tcc \
/usr/include/c++/3.3.1/cerrno /usr/include/errno.h \
/usr/include/sys/errno.h /usr/include/c++/3.3.1/cmath \
/usr/include/math.h /usr/include/c++/3.3.1/bits/cmath.tcc \
/usr/include/c++/3.3.1/typeinfo /usr/include/c++/3.3.1/ostream \
/usr/include/c++/3.3.1/bits/ostream.tcc \
/usr/include/c++/3.3.1/bits/sstream.tcc /usr/include/c++/3.3.1/fstream \
/usr/include/c++/3.3.1/i686-pc-cygwin/bits/basic_file.h \
/usr/include/c++/3.3.1/bits/fstream.tcc /usr/include/c++/3.3.1/deque \
/usr/include/c++/3.3.1/bits/stl_deque.h \
/usr/include/c++/3.3.1/bits/deque.tcc /usr/include/c++/3.3.1/map \
/usr/include/c++/3.3.1/bits/stl_tree.h \
/usr/include/c++/3.3.1/bits/stl_map.h \
/usr/include/c++/3.3.1/bits/stl_multimap.h sdanalysis.h \
/usr/include/c++/3.3.1/vector /usr/include/c++/3.3.1/bits/stl_vector.h \
/usr/include/c++/3.3.1/bits/stl_bvector.h \
/usr/include/c++/3.3.1/bits/vector.tcc ../libslparse/iparsenode.h \
/usr/include/c++/3.3.1/iostream ../libslparse/ifuncdef.h \
.../libslparse/ivardef.h ../libaqsistypes/sstring.h \
.../libslparse/icodegen.h shaderspec.h ../banshee/engine/nonspec.h \
.../banshee/engine/linkage.h ../banshee/engine/bool.h \
.../banshee/engine/list.h ../banshee/libcompat/regions.h \
.../banshee/libcompat/linkage.h ../banshee/dyckcfl/dyckcfl.h \
.../libslparse/parsenode.h ../libslparse/vardef.h \
.../libslparse/funcdef.h ../libaqsistypes/list.h
johnc wrote:
> I would suggest, as an experiment, that you should disable the indexer for
> each of your projects, just to see if it is the indexer which is starving
> out the UI thread.
> Unless you are including 100's of files, we should not encountered parse
> times > a few seconds.
>
> Feel free to email me offline to talk about the Task Tag parsing feature:
> jcamelon@ca.ibm.com.
>
> Thanks
> JohnC
|
|
|
| Re: Task Tags support [message #112144 is a reply to message #112090] |
Thu, 22 July 2004 12:52 |
John Camelon
Messages: 242
Registered: July 2009 |
Senior Member |
|
|
Thank you for your analysis, it is greatly appreciated.
My comments are inline.
JohnC
"Jonathan Ragan-Kelley" <katokop1@yahoo.com> wrote in message
news:cdn0vq$i84$1@eclipse.org...
> Well I've done some experimentation. First of all, I'm running the
> Eclipse 3.0 final with CDT 2.0 final on the latest Sun JDK 1.5.0 beta
> under Windows XP (fully patched), using the latest Cygwin toolchain.
> All these tests are performed with the C++ indexer *disabled* for the
> given project.
>
> Beginning with a large C++ project on which I'm working, I found that
> disabling indexing certainly did seem to help. I disabled the indexer
> completely, configured the Content Assist timeout to 20 secs, and
> restarted Eclipse. Under these conditions, with both Content Assist
> source settings (file+includes or current project) I consistently see
> lags of 6.5-7.5 seconds. Under an existing managed make test project
> consisting of a single plain C file which includes <GL/glut.h> and
> optionally string.h or a few other std-c headers, Content Assist makes
> suggestions in about 1.5 seconds. However, as soon as any C++ headers
> are added to the mix (I tried <string> and <vector> independently) the
> time to completion immediately jumps to almost exactly the 6.5-7.5
> seconds seen on my larger C++ project.
>
> Out of curiosity, I used GCC's -M flag to evaluate the full include
> dependencies of the larger project (included at the end of this
> message), and while the project is relatively large, because of making
> some minor use of STL, it indirectly includes 150(!) files. For
> comparison, the single-file project just including <string> includes
> about 70 headers. Both yield identical performance. Also of note is
> the fact that I get identical performance in both scenarios (large
> project with C++ includes or single-file project with C++ includes),
> whether I set the Content Assist scope to the current project or to the
> current file and all its includes.
We are in the process (for 2.0.1) of rewriting our Scanner as that is where
it seems many of our performance problems.
We are seeing significant savings in I/O and dealing with inclusions.
> I ran into my older problem of having code assist simply fail to find
> any completions when I created an empty managed-make C++ project
> containing only the following. In this case, only generic symbols could
> be discovered (e.g. "this", but never any local identifiers).
>
> class MyClass {
> public:
> MyClass() {
> // no completions available for any of these -- uncomment and try
> //pu
> //pri
> //pro
> //this->
> //metho
> //this->metho
> }
Content Assist works as a parse up to a particular offset. Due to this, we
do not have information that comes
after the constructor declaration. In order to achieve this, our
errorhandling has to be much more mature, as
usually after someone is code-completing, the code will not compile and we
need to make sure we skip over
the exact right amount of bogus code.
> ~MyClass();
> int method();
> int pub;
> protected:
> int prot;
> private:
> int priv;
> };
>
> Also, while for some reason my more complex projects do tend to return
> some results after 6.5-7.5 seconds, I consistently observe two
> significant errors in functionality:
>
> I observe a frustrating behavior where much of the time, the content
> assist drop-down disappears just as soon as it appears. This seems to
> happen in multiple contexts, and with multiple types of invocation
> (automatic invocation after a '.' or '->' operator, pressing ctrl+space
> mid-way through typing an identifier, or pressing ctrl+space immediately
> after an opening '<' in a template object declaration [e.g. 'vector<'
> then ctrl+space]). This happens almost completely consistently the
> first time a content assist is requested, and occasionally the second
> time this same request is made in direct succession, but it tends to
> stay open after several successive tried. This happens whether or not
> any other direct UI events are going off (it often happens even with the
> keyboard inactive, the mouse totally still, and window manager focus on
> the Eclipse editor region currently being used).
This is the garbage collection hitting at precisely the wrong time. For
2.0.1, we are trying to
significantly reduce our object-count, peak memory usage and total footprint
in the parser.
> Secondly, there seems to be a problem with namespace traversal using the
> '::' operator. Trying to traverse through the std namespace this way
> reveals substantial problems. std:: pauses then returns nothing.
> Subsequently pressing ctrl-space returns a seemingly correct list of
> options, and typing filters these options (as expected). But then, for
> example, typing std::vector:: + ctrl-space pauses for the usual 6-7
> seconds then returns only one option: "vector". Traversing this way
> leads to an infinite series of std::vector::vector::vector... types as
> the only option in the namespace. Clearly not what is expected. And
> std::string:: + ctrl-space reveals no options (it doesn't time out, it
> pauses for a number of seconds and then resumes with no time out
> warning), whereas std::string-> appears to expose nearly everything in
> the local namespace (objects and types in *my* project). Altogether
> strange. Indeed, I am now noticing that just ;\n -> + ctrl-space
> exhibits similar behavior.
Please raise a bug @ bugs.eclipse.org, on CDT w/component CDT-Parser
and I'll address it for the upcoming service release.
> I'm sorry to lump so many issues together, but as I said at first,
> Content Assist seems generally problematic. The performance issue is
> critical, but the functionality seems to exhibit other issues, as well.
>
> The clear and present conclusion which can be drawn from this, however,
> is that the main problems with Content Assist exist only in C++ land.
> Pure C fares quite well -- 1.5 second Assist lags for extremely simple
> files seem rather poky, but it generally works. Once C++ is introduced,
> the problems begin appearing. There are issues with general C++
> functionality, but above all, the current design clearly just cannot
> handle the complex include structure of the std-c++ libraries, or
> anything of the sort.
>
> I'm sure you all are seriously thinking about how this should be
> addressed, but it seems the assistant's search process should have the
> least trouble with exactly these libraries which throw it off the most
> today, since it can reasonably invest substantial resources in indexing
> and optimizing these paths, and since they are heavily included, their
> indices should generally remain cached from first use throughout a
> user's work on a project.
>
> I hope this helps at least somewhat. Below I've included the full
> indirect includes of the file on which I first observed this trouble.
> -jrk
>
> -- Large C++ Project ---------------------------------------------------
> g++ -M sdanalysis.cpp -I<all-necessary-include-paths> gives the following:
>
> sdanalysis.o: sdanalysis.cpp ../libaqsistypes/aqsis.h \
> ../libaqsistypes/config.h /usr/include/assert.h /usr/include/_ansi.h \
> /usr/include/newlib.h /usr/include/sys/config.h \
> /usr/include/machine/ieeefp.h /usr/include/cygwin/config.h \
> ../libaqsistypes/aqsis_types.h ../libaqsistypes/posix/aqsis_compiler.h \
> /usr/include/c++/3.3.1/sstream /usr/include/c++/3.3.1/istream \
> /usr/include/c++/3.3.1/ios /usr/include/c++/3.3.1/iosfwd \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/c++config.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/os_defines.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/c++locale.h \
> /usr/include/c++/3.3.1/clocale /usr/include/locale.h \
> /usr/include/c++/3.3.1/cctype /usr/include/ctype.h \
> /usr/include/c++/3.3.1/bits/stringfwd.h \
> /usr/include/c++/3.3.1/bits/fpos.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/c++io.h \
> /usr/include/c++/3.3.1/cstdio /usr/include/c++/3.3.1/cstddef \
> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/stddef.h \
> /usr/include/stdio.h \
> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/stdarg.h \
> /usr/include/sys/reent.h /usr/include/sys/_types.h \
> /usr/include/sys/types.h /usr/include/machine/types.h \
> /usr/include/sys/features.h /usr/include/cygwin/types.h \
> /usr/include/sys/sysmacros.h /usr/include/stdint.h \
> /usr/include/sys/stdio.h /usr/include/sys/lock.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/gthr.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/gthr-default.h \
> /usr/include/pthread.h /usr/include/signal.h /usr/include/sys/signal.h \
> /usr/include/cygwin/signal.h /usr/include/sched.h /usr/include/time.h \
> /usr/include/machine/time.h /usr/include/unistd.h \
> /usr/include/sys/unistd.h /usr/include/getopt.h \
> /usr/include/c++/3.3.1/cwchar /usr/include/c++/3.3.1/ctime \
> /usr/include/wchar.h /usr/include/c++/3.3.1/bits/functexcept.h \
> /usr/include/c++/3.3.1/exception_defines.h \
> /usr/include/c++/3.3.1/exception \
> /usr/include/c++/3.3.1/bits/char_traits.h \
> /usr/include/c++/3.3.1/cstring /usr/include/string.h \
> /usr/include/c++/3.3.1/bits/localefwd.h \
> /usr/include/c++/3.3.1/bits/ios_base.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/atomicity.h \
> /usr/include/c++/3.3.1/bits/locale_classes.h \
> /usr/include/c++/3.3.1/string /usr/include/c++/3.3.1/memory \
> /usr/include/c++/3.3.1/bits/stl_algobase.h \
> /usr/include/c++/3.3.1/climits \
> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/limits.h \
> /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include/syslimits.h \
> /usr/include/limits.h /usr/include/c++/3.3.1/cstdlib \
> /usr/include/stdlib.h /usr/include/machine/stdlib.h \
> /usr/include/alloca.h /usr/include/c++/3.3.1/new \
> /usr/include/c++/3.3.1/bits/stl_pair.h \
> /usr/include/c++/3.3.1/bits/type_traits.h \
> /usr/include/c++/3.3.1/bits/stl_iterator_base_types.h \
> /usr/include/c++/3.3.1/bits/stl_iterator_base_funcs.h \
> /usr/include/c++/3.3.1/bits/concept_check.h \
> /usr/include/c++/3.3.1/bits/stl_iterator.h \
> /usr/include/c++/3.3.1/bits/stl_alloc.h \
> /usr/include/c++/3.3.1/bits/stl_threads.h \
> /usr/include/c++/3.3.1/bits/stl_construct.h \
> /usr/include/c++/3.3.1/bits/stl_uninitialized.h \
> /usr/include/c++/3.3.1/bits/stl_raw_storage_iter.h \
> /usr/include/c++/3.3.1/bits/stl_function.h \
> /usr/include/c++/3.3.1/bits/basic_string.h \
> /usr/include/c++/3.3.1/algorithm \
> /usr/include/c++/3.3.1/bits/stl_algo.h \
> /usr/include/c++/3.3.1/bits/stl_heap.h \
> /usr/include/c++/3.3.1/bits/stl_tempbuf.h \
> /usr/include/c++/3.3.1/bits/basic_string.tcc \
> /usr/include/c++/3.3.1/streambuf \
> /usr/include/c++/3.3.1/bits/streambuf.tcc \
> /usr/include/c++/3.3.1/bits/basic_ios.h \
> /usr/include/c++/3.3.1/bits/streambuf_iterator.h \
> /usr/include/c++/3.3.1/bits/locale_facets.h \
> /usr/include/c++/3.3.1/cwctype /usr/include/wctype.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/ctype_base.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/ctype_inline.h \
> /usr/include/c++/3.3.1/bits/codecvt.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/time_members.h \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/messages_members. h \
> /usr/include/c++/3.3.1/bits/basic_ios.tcc \
> /usr/include/c++/3.3.1/limits \
> /usr/include/c++/3.3.1/bits/istream.tcc /usr/include/c++/3.3.1/locale \
> /usr/include/c++/3.3.1/bits/locale_facets.tcc \
> /usr/include/c++/3.3.1/cerrno /usr/include/errno.h \
> /usr/include/sys/errno.h /usr/include/c++/3.3.1/cmath \
> /usr/include/math.h /usr/include/c++/3.3.1/bits/cmath.tcc \
> /usr/include/c++/3.3.1/typeinfo /usr/include/c++/3.3.1/ostream \
> /usr/include/c++/3.3.1/bits/ostream.tcc \
> /usr/include/c++/3.3.1/bits/sstream.tcc /usr/include/c++/3.3.1/fstream \
> /usr/include/c++/3.3.1/i686-pc-cygwin/bits/basic_file.h \
> /usr/include/c++/3.3.1/bits/fstream.tcc /usr/include/c++/3.3.1/deque \
> /usr/include/c++/3.3.1/bits/stl_deque.h \
> /usr/include/c++/3.3.1/bits/deque.tcc /usr/include/c++/3.3.1/map \
> /usr/include/c++/3.3.1/bits/stl_tree.h \
> /usr/include/c++/3.3.1/bits/stl_map.h \
> /usr/include/c++/3.3.1/bits/stl_multimap.h sdanalysis.h \
> /usr/include/c++/3.3.1/vector /usr/include/c++/3.3.1/bits/stl_vector.h \
> /usr/include/c++/3.3.1/bits/stl_bvector.h \
> /usr/include/c++/3.3.1/bits/vector.tcc ../libslparse/iparsenode.h \
> /usr/include/c++/3.3.1/iostream ../libslparse/ifuncdef.h \
> ../libslparse/ivardef.h ../libaqsistypes/sstring.h \
> ../libslparse/icodegen.h shaderspec.h ../banshee/engine/nonspec.h \
> ../banshee/engine/linkage.h ../banshee/engine/bool.h \
> ../banshee/engine/list.h ../banshee/libcompat/regions.h \
> ../banshee/libcompat/linkage.h ../banshee/dyckcfl/dyckcfl.h \
> ../libslparse/parsenode.h ../libslparse/vardef.h \
> ../libslparse/funcdef.h ../libaqsistypes/list.h
>
> johnc wrote:
>
> > I would suggest, as an experiment, that you should disable the indexer
for
> > each of your projects, just to see if it is the indexer which is
starving
> > out the UI thread.
> > Unless you are including 100's of files, we should not encountered parse
> > times > a few seconds.
> >
> > Feel free to email me offline to talk about the Task Tag parsing
feature:
> > jcamelon@ca.ibm.com.
> >
> > Thanks
> > JohnC
|
|
|
Goto Forum:
Current Time: Mon Jul 22 00:20:40 GMT 2024
Powered by FUDForum. Page generated in 0.04361 seconds |
] 
Search
Help
Register
Login
Home
