On 11/22/2010 08:36 AM, Jed Brown wrote:
> On Sun, 21 Nov 2010 22:26:27 -0500, "Eric M. Ludlam"<eric@...> wrote:
>> Hi,
>>
>> I'll guess that PETSCTS_DLLEXPORT is a macro that Semantic doesn't have
>> in its macro tables. Semantic only pulls macros from headers you
>> explicitly list for it. I can't pull macros from headers dynamically
>> for two reasons. One is it is a performance issue, and it usually
>> doesn't matter.
>
> Thanks Eric. What are your thoughts about backing semantic's cache with
> a "real" database like SQLite or Berkeley DB?
I think that's a fine idea, and the Semanticdb back-end is designed so
that any number of storage types could be done with ease.
I also think Semantic's entire DB system needs to be moved out of the
Emacs process. Using sql is one thing, but the tags will still end up
in Emacs memory, and large projects will swamp Emacs's memory footprint
with stuff.
This is one of the next projects that needs to be tackled after the bzr
rename is done.
> For me, the most visible performance issue is probably semantic-symref,
> which somehow takes noticeably longer to return than "global", which it
> is supposed to be using internally. 15 to 20 seconds for this query is
> not uncommon on a 400 kLOC (15 MB) project, but with notmuch (emacs
> interface, C library, Xapian-backed) I have full text search of a 5 GB
> mail store in under 2 seconds. I would use semantic-symref much more
> often if it took less than 2 seconds.
The performance with symref is not in calling gnu global. Semantic
visits every hit, and identifies the function calling the reference in
question, and that is the slow part. In theory you could write a
utility that builds a call tree, but that hasn't been done. There isn't
a way to turn it off in the lists mode w/out coding something. If you
write your own utility w/ the symref API, you can skip that step and,
naturally, do whatever you want with the raw data.
>> The second is that Semantic has to parse the file
>> before it can identify headers that might contribute to macros that
>> affect parsing the file.
>
> Does this mean that semantic does not parse the headers in order? What
> is the reason for this?
Semantic parses the file ignoring includes. At some random point later,
it parses the headers in the order that they appear in a breadth-first
order.
>> Anyway, add the header that has your defines to
>> semantic-lex-c-preprocessor-symbol-file, and then delete your cache
>> files in ~/.semanticdb and restart Emacs to make sure the updating
>> parsing works. There is no easy way to do it from within Emacs.
>
> How do I get a trace to find out what's happening here? I tried
> debug-on-entry, but that function is created by a macro so the debugger
> isn't very helpful at telling me what is going on.
>
> Idle Service Error semantic-idle-local-symbol-highlight-idle-function: "#<buffer ex14.c> - Wrong type argument: arrayp, nil"
In semantic-c.el there is:
semantic-c-reset-preprocessor-symbol-map
which does the resetting of the macro table. That's called once unless
you use customize to change features, or call
semantic-c-add-preprocessor-symbol yourself.
Alternately, semantic-lex-spp-project-macro-symbol-obarray can be setup
by ede in ede-apply-preprocessor-map which calls the method
ede-preprocessor-map off whatever the EDE target belonging to the given
file is. That allows a project to specify macros or macro files (like
ede-cpp-root, or ede-generic) unique to a given set of source files.
Eric
|