On 03/19/2013 11:06 AM, Barry OReilly wrote:
> > You pass... what? Are those seriously 420 *separate* include
> > directories, meaning do you pass those 420 directories to the compiler
> > via "-I"? Does that even fit on the command line?
> That's the number of include directories in the whole project, including
> UT and integration test code. A given invocation of g++ has a subset.
> The compilation of the .cc in question has 19 -I flags.
I had similar problems where I work. I ended up writing a custom EDE
project to cut back on the # of include paths needed for a given source,
since different areas had different sets of includes. Even so, for me
if I pulled in sources from too many modules, Emacs would eventually
load so much data, the machine spent all its time swapping.
Writing a custom EDE project is not for everyone though. ;)
For your case, you might be able to tag subsets of your project as
independent projects instead. That depends on if they cross-ref each other.
Lastly, another idea is to implement a :locate-fcn for your
cpp-root-project that knows which includes belong to which subsections
of your project. In that way, it will only load in database caches for
include directories that matter, instead of for the entire project.
> > You could take a look with the ELP profiler what is taking so long.
> Thanks for your guidance.
> Looking at the output, it appears to be a matter of
> semanticdb-find-table-for-include* functions being called for each
> include (1238 is pretty close to 1166 Boost headers + 63 source tree
> headers). I suppose cutting down on the 420 include paths wouldn't help
> since the performance seems to be a function of the number of files
> actually included. Does that sound correct to you?
> semantic-ia-fast-jump 1
[ ... ]
> semanticdb-find-table-for-include 1238
> 36.202804999 0.0292429765
> semanticdb-find-table-for-include-c-mode 1238
> 36.193572000 0.0292355185
> semanticdb-find-table-for-include-default 1238
> 36.186072999 0.0292294612
> semantic-dependency-tag-file 1193
> 31.026644999 0.0260072464
This shows that it is snooping around your file system for include
files. Once found, the path is cached in the tag and doesn't need to be
looked up a second time.
For this case, shrinking the include path will help. It could also help
if you add a ':locate-fcn' as describe above which is somehow smarter
about identifying where your files are than a simple rummage around the FS.
> semantic-sort-tags-by-name-then-type-increasing 3310
> 13.898089999 0.0041988187
My first thought is that this was part of the typecache which is built
up for your first completion, but I don't see the rest of the API in the
ELP output. This is another complex data structure that isn't saved,
and is a huge database of all your types. It gets rebuilt regularly,
but secondary builds are usually best-case scenario with most of the
list already sorted.
For this case, tuning the project to minimize the number of include
files needed will help.
For example, if your files include "unecessary_defs.hh", you might
choose to remove that from your include path if you never need to access
those names via semantic. My system at work had this monster-sized
util.h which had mostly fcns in it, and a bunch of crazy data types I
never used which weren't really needed for completing stuff in the code
I worked on, so I could skip loading it.
For my system at work, it used to take 8 minutes the first time for a
completion, and I managed to get it down to something pretty reasonable,
and instantaneous the second time. In this case, it's just big so it
will take effort to tune things to minimize the scope.