Why code completion using CEDET in Emacs so slow?

Why code completion using CEDET in Emacs so slow?

[Judeau]

I recently try KDevelop. It looks up for symbols (variables, function names,
class, struct...) much faster (instantly) than semantic-complete-self-insert
or M-Ret. Using M-Ret is faster, but it does not have nice format like other
IDEs, such as From nil > . In emacs, I must wait for at least ~1 sec, in
many cases, waiting for CEDET to look up all the header files in an included
header files, which takes very long.

I used auto complete clang, but it seems to have no speed improvement. Why
is that :( ? I love Emacs and all, and been using it for my C/C++ for almost
a year until I discover KDevelop. Using Emacs means code completion should
be trivial and optional? I really love this Emacs as an editor and as an
"IDE". I just want to find a way to improve this.

I notice that when performing auto complete, my disk got accessed a lot. Is
there a way to make the included files stored in memory for faster look up?
Or should CEDET implement this way?

-- 
View this message in context: http://old.nabble.com/Why-code-completion-using-CEDET-in-Emacs-so-slow--tp32638310p32638310.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: Why code completion using CEDET in Emacs so slow?

[David Engster]

Judeau writes:
> I recently try KDevelop. It looks up for symbols (variables, function names,
> class, struct...) much faster (instantly) than semantic-complete-self-insert
> or M-Ret. Using M-Ret is faster, but it does not have nice format like other
> IDEs, such as From nil > . In emacs, I must wait for at least ~1 sec, in
> many cases, waiting for CEDET to look up all the header files in an included
> header files, which takes very long.

CEDET will parse the headers once. They will be read from disk cache
afterwards.

> I used auto complete clang, but it seems to have no speed improvement. Why
> is that :( ?

I have no idea. Maybe CEDET isn't compiled correctly?

> I love Emacs and all, and been using it for my C/C++ for almost
> a year until I discover KDevelop. Using Emacs means code completion should
> be trivial and optional? I really love this Emacs as an editor and as an
> "IDE". I just want to find a way to improve this.
>
> I notice that when performing auto complete, my disk got accessed a lot. Is
> there a way to make the included files stored in memory for faster look up?
> Or should CEDET implement this way?

Maybe your project is simply very large? Could you give some concrete
examples where completions are too slow for you? Maybe CEDET can be
tuned to your project by excluding some headers which slow down
completion.

-David

Re: Why code completion using CEDET in Emacs so slow?

[Judeau]

David Engster wrote:
> 
> 
>> I used auto complete clang, but it seems to have no speed improvement.
>> Why
>> is that :( ?
> 
> I have no idea. Maybe CEDET isn't compiled correctly?
> 
I byte-compiled CEDET and setting up correctly without any error.



David Engster wrote:
> 
>> I love Emacs and all, and been using it for my C/C++ for almost
>> a year until I discover KDevelop. Using Emacs means code completion
>> should
>> be trivial and optional? I really love this Emacs as an editor and as an
>> "IDE". I just want to find a way to improve this.
>>
>> I notice that when performing auto complete, my disk got accessed a lot.
>> Is
>> there a way to make the included files stored in memory for faster look
>> up?
>> Or should CEDET implement this way?
> 
> Maybe your project is simply very large? Could you give some concrete
> examples where completions are too slow for you? Maybe CEDET can be
> tuned to your project by excluding some headers which slow down
> completion.
> 
> -David
> 
I want to use the boost header files. Every time I include a new header file
in the boost library, it takes pretty long to parse. 

I used boost asio, and it always takes a few seconds for the first look up.
The second look up (means cached) is a brief. delay. Meanwhile, using
Eclipse CDT or KDevelop, after I include the header file such as
boost/asio.hpp , the symbols in the header file (and related files in the
header) are automatically available for look up instantly without any delay
(just like the usual feeling when programming with Java in an IDE). However,
in order for Eclipse to "see" the symbol, I must specified the library &
link path for a particular project. 

For that reason, also since my company is using Eclipse, I end up using
Eclipse with Emacs key binding, which is a neat combination. But, I still
want to make my Emacs environment better, simply because its key binding and
command system is really nice for productivity. 

And, with autocomplete.el, autocomplete is usually sufficient, mainly even
without completion or not, we usually have to look up for the function in
the document anyway. Afterward, autocomplete.el does it job nicely.

-- 
View this message in context: http://old.nabble.com/Why-code-completion-using-CEDET-in-Emacs-so-slow--tp32638310p32640322.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: Why code completion using CEDET in Emacs so slow?

[David Engster]

Judeau writes:
> I want to use the boost header files. Every time I include a new header file
> in the boost library, it takes pretty long to parse. 

Yes, boost is a huge library with very complicated constructs, so
parsing takes time.

> I used boost asio, and it always takes a few seconds for the first look up.
> The second look up (means cached) is a brief. delay. 

> Meanwhile, using Eclipse CDT or KDevelop, after I include the header
> file such as boost/asio.hpp , the symbols in the header file (and
> related files in the header) are automatically available for look up
> instantly without any delay (just like the usual feeling when
> programming with Java in an IDE).

Yes. CEDET is written in Emacs Lisp, so it will always be slower than
those programs. Still, it should always be usable. Could you provide an
example file using boost::asio which demonstrates the slow completion?

-David

Re: Why code completion using CEDET in Emacs so slow?

[Judeau]

David Engster wrote:
> 
> Yes. CEDET is written in Emacs Lisp, so it will always be slower than
> those programs. Still, it should always be usable. Could you provide an
> example file using boost::asio which demonstrates the slow completion?
> 
> -David
> 
I edited and supplied one example in above post. When I look up everything
in boost:: namespace, it takes a long time. For small project, it is always
usable and fast enough, but parsing included files from large library is
always long, and every time a new symbol is looked up if I use
semantic-complete-self-insert for every member selection (using . or ->, it
still has a brief delay i ,which is still annoying. After the first time,
everything seems fine, sometimes a brief delay happens when look up, but
usually it is instant. Because of the time taken to parse, I usually type
manually and use auto-complete mode instead.

Due to this reason, I have hard time to convince people to start trying
Emacs.
-- 
View this message in context: http://old.nabble.com/Why-code-completion-using-CEDET-in-Emacs-so-slow--tp32638310p32640549.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: Why code completion using CEDET in Emacs so slow?

[David Engster]

Judeau writes:
> David Engster wrote:
>> 
>> Yes. CEDET is written in Emacs Lisp, so it will always be slower than
>> those programs. Still, it should always be usable. Could you provide an
>> example file using boost::asio which demonstrates the slow completion?
>> 
>> -David
>> 
> I edited and supplied one example in above post.

I'm afraid I can't see any code there.

-David

Re: Why code completion using CEDET in Emacs so slow?

[Judeau]

David Engster wrote:
> 
> I'm afraid I can't see any code there.
> 
> -David
> 
As I said, if you include new file every time, it will have a brief delay
when looking up members. If you try to delete .semanticdb (back up it
first), and/or try code completion for every new file included. It always
takes a brief delay depends on how large the looking up scope. For example:

(local-set-key "\C-c>" 'semantic-complete-analyze-inline)

When I try to look up symbols in a namespace (such as std:: or boost::) with
semantic-complete-analyze-inline using C-c > , or when looking up class
members in map, set, boost types..., I always have to wait for a while.
Well, I guess I will have to accept this and not to rely to much on code
completion then, since it would be slower than I type it manually if the
looking up scope is greater medium (for my own classes placed locally in my
project, it is enough). Still, using autocomplete.el works better for me.

I don't know is there a way to update .semanticdb? It seems to me after the
first time scan, if I update the file (such as add more function
declarations), it won't rescan and save to update.
-- 
View this message in context: http://old.nabble.com/Why-code-completion-using-CEDET-in-Emacs-so-slow--tp32638310p32642812.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: Why code completion using CEDET in Emacs so slow?

[David Engster]

Judeau writes:
> David Engster wrote:
>> 
>> I'm afraid I can't see any code there.
>> 
>> -David
>> 
> As I said, if you include new file every time, it will have a brief delay
> when looking up members. If you try to delete .semanticdb (back up it
> first), and/or try code completion for every new file included. It always
> takes a brief delay depends on how large the looking up scope. For example:
>
> (local-set-key "\C-c>" 'semantic-complete-analyze-inline)
>
> When I try to look up symbols in a namespace (such as std:: or boost::) with
> semantic-complete-analyze-inline using C-c > , or when looking up class
> members in map, set, boost types..., I always have to wait for a while.
> Well, I guess I will have to accept this and not to rely to much on code
> completion then, since it would be slower than I type it manually if the
> looking up scope is greater medium (for my own classes placed locally in my
> project, it is enough). Still, using autocomplete.el works better for me.

Looking up everything in std:: will surely take some time. I mean, that
namespace is huge, with thousands of members. I believe you that
Eclipse/KDevelop do this much quicker, and while there may be some
potential for optimization in CEDET, it is really pushing what you can
still do in Emacs Lisp. We will probably end up coding some of the
database and parsing stuff in C, but there's more urgent stuff to do at
the moment.

> I don't know is there a way to update .semanticdb? It seems to me after the
> first time scan, if I update the file (such as add more function
> declarations), it won't rescan and save to update.

Yes, that's what CEDET does. It will update semanticdb automatically if
needed, i.e., if you #include new headers or change one of the headers.

Here's a little benchmark I did, using this:

--------------------
/* (benchmark-run
     (progn
       (search-forward "boost::asio::")
       (semantic-analyze-possible-completions (semantic-analyze-current-context))))
*/

#include <iostream>
#include <boost/asio.hpp>

int main()
{
   boost::asio::
}
======================

Just go behind the last bracket of the comment and hit C-x C-e to time
this call. If you delete everything in ~/.semanticdb, this will parse
lots of STL and boost stuff and takes about 2:20m on my
machine. Afterwards, this should take about 0.15 seconds (you have to
enter a newline in the main function or something, otherwise it will be
much quicker due to caching).

If you restart Emacs, CEDET will have to read the cache-files first,
which takes about 3-4 seconds on my machine. Afterwards, it will again
be around 0.15 seconds.

If you try to complete only "boost::" or "std::", it will be much slower
because those namespaces simply have lots and lots of members. If you
just want to safe some keystrokes and do not depend on actual "smart"
completions, you might be happier with tools like etags/ctags or GNU
global, and only use CEDET when you actually need context-aware
completions.

-David