emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDE


From: Oleh Krehel
Subject: Re: IDE
Date: Tue, 27 Oct 2015 09:21:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Dmitry Gutov <address@hidden>
>> Date: Sat, 24 Oct 2015 21:15:18 +0300
>> Cc: address@hidden, address@hidden, address@hidden,
>>      address@hidden, address@hidden
>> 
>> > Once again, the issue is not the format of the database.  That's
>> > immaterial.
>> 
>> Database format can have a real performance impact.
>
> Yes, but the issue is performance, not the database format.

If I understood correctly what you mean by the database format, it
matters to me. The TAGS files are too simplistic, they don't understand
the language, either C and especially C++.  On the other hand, have a
look that these Semantic tags entries for e.g. etags.c:

("regex.h" include (:system-flag t) nil [4626 4644])
("CTAGS" variable (:constant-flag t) nil [4934 4939])
("streq" function
         (:typemodifiers ("static")
                         :arguments 
                         ( ("s" variable
                                (:pointer 1
                                          :constant-flag t
                                          :type "char")
                                (reparse-symbol arg-sub-list) [4973 4987])
                           ("t" variable
                                (:pointer 1
                                          :constant-flag t
                                          :type "char")
                                (reparse-symbol arg-sub-list) [4988 5002]))     
             
                         :type "bool")
         nil [4954 5035])

This is a lot of useful information in a readable and usable format.
The only problem is that it's a little slow to parse: 190 files in
emacs/src take around 30 seconds for a full reparse. But then, all this
info is kept and is re-parsed only on timestamp changes.

I did a caching optimization for `moo-jump-local' from function-args
package. When called without update it takes <0.1s to bring up all 19356
semantic tags. The update (through a call with "C-u") takes ~3 seconds +
reparse time for any out-of-date file.

My point is that because `moo-jump-local' uses semantic, it's a lot more
precise than e.g. `ggtags-find-definition' that gives only the names of
9956 tags, with no semantic information.

Compare:

    MAX_PARAGRAPH_SEARCH
    x_parse_color

to:

#include <dispextern.h>                                                         
                  xterm.h
#include <termhooks.h>                                                          
                  xterm.h
#define BLACK_PIX_DEFAULT                                                       
                  xterm.h
#define WHITE_PIX_DEFAULT                                                       
                  xterm.h
#define STANDARD_EVENT_SET                                                      
                  xterm.h
x_bitmap_record                                                                 
                  xterm.h
  Pixmap pixmap                                                                 
                  xterm.h
  bool have_mask                                                                
                  xterm.h
  Pixmap mask                                                                   
                  xterm.h
  char* file                                                                    
                  xterm.h
  int refcount                                                                  
                  xterm.h
  int height                                                                    
                  xterm.h
  int width                                                                     
                  xterm.h
  int depth                                                                     
                  xterm.h
color_name_cache_entry                                                          
                  xterm.h
  color_name_cache_entry* next                                                  
                  xterm.h
  XColor rgb                                                                    
                  xterm.h
  char* name                                                                    
                  xterm.h
Status x_parse_color (frame *f, const char *color_name, XColor *color);         
                  xterm.h

In my opinion, the tags format of semantic is very good, much better
than plain TAGS. Maybe some work needs to be done to make them generate
faster/more precise, e.g. make GCC output these tags files.
    



reply via email to

[Prev in Thread] Current Thread [Next in Thread]