[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.
- Re: IDE, (continued)
- Re: IDE, Eli Zaretskii, 2015/10/26
- Re: IDE, Andreas Schwab, 2015/10/27
- Re: IDE, Marcus Harnisch, 2015/10/27
- Re: IDE, Dmitry Gutov, 2015/10/24
- Re: IDE, Eli Zaretskii, 2015/10/24
- Re: IDE, Dmitry Gutov, 2015/10/24
- Re: IDE, Eli Zaretskii, 2015/10/24
- Re: IDE, Dmitry Gutov, 2015/10/24
- Re: IDE, Eli Zaretskii, 2015/10/24
- Re: IDE, Dmitry Gutov, 2015/10/24
- Re: IDE,
Oleh Krehel <=
- Re: IDE, Eli Zaretskii, 2015/10/27
- RE: IDE, Drew Adams, 2015/10/24
- Re: IDE, Eric Ludlam, 2015/10/10
- Re: IDE, Dmitry Gutov, 2015/10/12
- Re: IDE, Eli Zaretskii, 2015/10/11
- Re: IDE, David Kastrup, 2015/10/11
- Re: IDE, Eli Zaretskii, 2015/10/15
- Re: IDE, Dmitry Gutov, 2015/10/11
- Re: IDE, Eric Ludlam, 2015/10/15
- Re: IDE, Dmitry Gutov, 2015/10/12