File-granular information is considered details.
Depends on D88411
Paths
| Differential D88414
[clangd] Introduce memory dumping to FileIndex, FileSymbols and BackgroundIndex ClosedPublic Authored by kadircet on Sep 28 2020, 6:18 AM.
Details
Diff Detail
Event Timeline
kadircet marked 4 inline comments as done. Comment Actions
kadircet added a child revision: D88417: [clangd] Record memory usages after each notification.Oct 7 2020, 8:45 AM Comment Actions Now there's lots of usage (which looks good!) i'm finding it a bit hard to keep track of what the tree will look like overall. At some point it'd be great to: This revision is now accepted and ready to land.Oct 7 2020, 9:51 AM Comment Actions
i was also thinking about it and couldn't decide between a "custom command" vs "code action".
I am happy to go with the "code action" approach initially. WDYT? (not in the scope of this patch) Comment Actions
Comment Actions
I'm pretty leery about code action because it's not at all context-sensitive (not even per-file). Comment Actions
Another slighty silly reason: because of layering, a code action is going to have a hard time getting at ClangdLSPServer's profile (or even ClangdServer's). (We could work around this in various ways, but I think we'll create a bit of a mess) This revision was landed with ongoing or failed builds.Oct 12 2020, 6:27 AM Closed by commit rGa74d59494861: [clangd] Introduce memory dumping to FileIndex, FileSymbols and BackgroundIndex (authored by kadircet). · Explain Why This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 296971 clang-tools-extra/clangd/index/Background.h
clang-tools-extra/clangd/index/Background.cpp
clang-tools-extra/clangd/index/FileIndex.h
clang-tools-extra/clangd/index/FileIndex.cpp
clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
clang-tools-extra/clangd/unittests/FileIndexTests.cpp
|
As a conventional name for these, profile() or so might be slightly more evocative. And I think we should push this into progressively more places (that currently have ad-hoc "estimate" accessors) so the brevity is reasonable I think.
(If not, I'd even slightly prefer "record"/"measure" over "attach" as emphasizing the high-level operation rather than the data structure used can help readability)