Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDT/calls/Indexing20112006"

< CDT‎ | calls
Line 45: Line 45:
 
* Doug/Markus will keep profiling to see what is happening.
 
* Doug/Markus will keep profiling to see what is happening.
 
* Performance testing is held up by a bugzilla. https://bugs.eclipse.org/bugs/show_bug.cgi?id=163986 . We'll give it more time before escalating again.
 
* Performance testing is held up by a bugzilla. https://bugs.eclipse.org/bugs/show_bug.cgi?id=163986 . We'll give it more time before escalating again.
 +
 +
* Andrew F. asks what people think of the idea of asking Andrew Niefer to give an overview of the binding routines. Markus feels its better to have specific questions. Doug suggests waiting until Markus has completed his experiments with moving pdom binding resolution first.
 +
 +
* Jason is currently implementing a stubbed out IIndex interface so the parser can be invoked without needing the IIndex present. Markus's potential changes in this area should not change this, as the parser still does not need the index if the sources are complete. That is, if you're doing a full parse, then the index is not necessary.

Revision as of 11:57, 20 November 2006

Call information

20/11/2006, 15:00 UTC

Toll Free: 1-866-797-9099
Global Tool Free: 800 7279-1480
Local: 613-787-5142
Conf ID: 2679242

Agenda

  • Index based binding resolution in AST
  • Indexing strategies
    • Indexing all files vs. sources built
    • Stopping indexer on errors
  • Paths in the PDOM
  • Regression in indexing performance

Attendees

Content

  • Looks like binding resolution is going through both the existing binding resolution logic and some additional logic in the linkage classes. Original intent was to go purely through the resolution logic written by Andrew Niefer. Concern that the real knowledge/expertise lies with Andrew.
    • Markus will spend the next week investigating in detail reusing the DOM resolution routines (last week in November)
  • Doug says the choice of whether to index all project resources, or just those involved in the build (ie referenced in a inclusino tree) has a long history. Consensus is to have a ui preference when someone has time to do this.
  • Markus has increased the error count to 500 for now. We might want to reduce this for release.
  • Paths in the PDOM. Not everyone has had time to look at the proposal. Markus suggests using a tuple (URI, String == getFullPath()) to avoid the overhead of translating from URI to IResource which involves a search. Andrew to post an update to the patch this afternoon. Doug says having include path entries as linked resources is not a big requirement. Getting an outline view for external resources is still an issue.
  • Some discussion of where the index code lives (currently parser directory), maybe it should be moved to the core directory. Some discussion of IIndex referencing CoreException and IProgressMonitor - this is not ideal for IBM's remote indexing scenario.
  • The indexing performance has regressed by an order of magnitude. Markus has done some profiling and reports
    • determining if a method is static is expensive
    • pdom lookup is not fast enough
  • Doug says the size of the pdoms has not got much bigger. Markus reports full indexer took 2hrs on firefox.
  • Doug/Markus will keep profiling to see what is happening.
  • Performance testing is held up by a bugzilla. https://bugs.eclipse.org/bugs/show_bug.cgi?id=163986 . We'll give it more time before escalating again.
  • Andrew F. asks what people think of the idea of asking Andrew Niefer to give an overview of the binding routines. Markus feels its better to have specific questions. Doug suggests waiting until Markus has completed his experiments with moving pdom binding resolution first.
  • Jason is currently implementing a stubbed out IIndex interface so the parser can be invoked without needing the IIndex present. Markus's potential changes in this area should not change this, as the parser still does not need the index if the sources are complete. That is, if you're doing a full parse, then the index is not necessary.

Back to the top