sammccall added a comment. In D59407#1447070 <https://reviews.llvm.org/D59407#1447070>, @nridge wrote:
> @sammccall, thank you for having a look at this. > > I have no objection to revising the data model if there's agreement on a > better one. > > In D59407#1446464 <https://reviews.llvm.org/D59407#1446464>, @sammccall wrote: > > > - I don't think we yet know what the more resource-critical (denser) > > relations and queries are, so it's unclear what to optimize for > > > Based on a brief mental survey of C++ IDE features I'm familiar with, I can > think of the following additional uses of the relations capability: > > - A call hierarchy feature (which is also proposed for LSP > <https://github.com/Microsoft/language-server-protocol/issues/468>, with > client <https://github.com/theia-ide/theia/issues/3765> and server > <https://github.com/Microsoft/vscode-languageserver-node/pull/420> > implementation efforts) would need every caller-callee relationship to be > recorded in the index (`RelationCalledBy`). > - Given a virtual method declaration, a user may want to see a list of > implementations (overriders) and navigate to one or more of them. This would > need every overrider relationship to be recorded in the index > (`RelationOverrideOf`). > > Intuitively, it seems like `RelationOverrideOf` would be slightly denser > than `RelationChildOf` (though not by much), while `RelationCalledBy` would > be significantly denser. In terms of queries, I believe the key for lookups > for both of the above would be a (subject, predicate) pair, just like for > subtypes. > > Does that change your analysis at all? Sorry for the slow response here. Override and callgraph are great examples! As you say, override is probably pretty sparse and it's probably not worth worrying about the storage too much. If we stored a callgraph we'd definitely need to worry about the representation though. The space-saving hierarchy in this case would be map<relationtype, map<callee, caller>>I guess. Maybe storing one `vector<pair<Subject, Predicate>>` for each relationship type would work here - querying for a bunch of relationship types is rare. One thing that strikes me here is that this case is very similar to our existing Ref data - it's basically a subset, but with a symbolid payload instead of location. We could consider just adding the SymbolID to Refs - it'd blow up the size of that by 50%, but we may not do much better with some other representation, and it would avoid adding any new complexity. Ultimately it may also be that supporting both find references and callgraph (which provide closely overlapping functionality) isn't a good use of index memory. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59407/new/ https://reviews.llvm.org/D59407 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
