[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Indexing in 6.0.2
|
Steve,
that's good news.
The read-only PDOMs are acessed via the same
techniques as the project PDOM. So, no they are not loaded
into
memory. All PDOMs share a memory cache, the maximum size of
which you can configure in the preferences.
When using read-only pdoms an additional layer that
combines multiple PDOMs to an index comes into play. It does use some
additional memory, however that should not count up to 200M. I would think that
there is a bug that causes the
additional memory consumption.
Markus.
Thanks Markus. You convinced me I needed to look
into this deeper and sure enough I think I've identified the difference
between 6.0.1 and 6.0.2 for me. I recently started using
the ReadOnlyPDOMProvider feature of the CIndex extension point and
the difference between 6.0.1 and 6.0.2 seems to be in the way that
symbols/files in the external pdom are handled. In 6.0.1, those
symbols/files are added to the project's index, while in 6.0.2, they are
not. This seems to be a "good thing" to me since it reduces the size of
the project's index file.
The increased memory usage in 6.0.2 seems to be related
to the size of the external pdom--which happens to be around 200M. If I
disable the external pdom, then 6.0.2 behaves the same as 6.0.1 (in terms of
memory usage and size of project index produced). Are external pdoms
read into memory?
Steve Kennedy
Alcatel-Lucent
Hi Steve,
there should not be much of a difference between 6.0.1
and 6.0.2. Please raise a bug so that we can track the
issue
until it is resolved.
It is unlikely that there is such a great differnece in
the number of files actually parsed. It might be the case that we have
a problem in counting the files, I'll need to double check. You can
help by providing the following information:
How do the resulting databases
(workspace/.metadata/.plugins/org.eclipse.cdt.core/*.pdom compare in
size?
What's the exact version you have been testing
with?
You can trace the application to figure out the exact
sequence of files being parsed.
Tracing the CDT indexer:
* use command line option
-debug <options-file>
* put the following in the options
file:
# turns on tracing for the cdt-core
plugin
org.eclipse.cdt.core/debug=true
# Reports sequence of files
indexed
org.eclipse.cdt.core/debug/indexer/activity=true
# Reports statistics for
indexer
org.eclipse.cdt.core/debug/indexer/statistics=false
# Reports unresolved inclusions for
indexer
org.eclipse.cdt.core/debug/indexer/problems/inclusion=false
# Reports scanner-problems for indexer (other than
unresolved
includes)
org.eclipse.cdt.core/debug/indexer/problems/scanner=false
# Reports syntax-problems for
indexer
org.eclipse.cdt.core/debug/indexer/problems/syntax=false
# Reports problems for indexer, including inclusion-,
scanner-, syntax- and
resolution-problems.
org.eclipse.cdt.core/debug/indexer/problems=false
I've been playing around with 6.0.2 integration builds because and
I've noticed a couple of big differences in indexing behavior compared
with 6.0.1:
- Increased heap usage in 6.0.2 during indexing
With 6.0.1, I could index my project with -Xmx400m. In 6.0.2, I
need -Xmx600m to avoid out of memory or horrible performance. Any
ideas why?
- Fewer headers are being indexed (same code base, same
settings):
6.0.1: C/C++ Indexer: Project 'all' (2021 sources, 8072
headers)
6.0.2: C/C++ Indexer: Project 'all' (2021 sources, 3581
headers)
Since in neither case am I getting any inclusion errors, I'm
wondering if in 6.0.1 the extra 4,500 header were being indexed
unnecessarily? "Index source files not included in the build" and
"Index unused headers" are both unchecked in the Preferences.
Thanks,
Steve Kennedy
Alcatel-Lucent
