We used to scan the code everytime when computing the LSP position to the offset
(respect the LSP encoding).
Details
- Reviewers
ilya-biryukov - Commits
- rG8805316172a6: [clangd] Speed up when building rename edit.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/SourceCode.h | ||
---|---|---|
54 ↗ | (On Diff #230065) | How this is different from positionToOffset with Pos.line = 0 and Pos.column = LSPCharacter? |
clang-tools-extra/clangd/refactor/Rename.cpp | ||
444 | We are aiming to convert all ranges in O(n) instead of O(n^2), right? assert(llvm::is_sorted(Occurences)); // These two always correspond to the same position. Position LastPos = Position{0, 0}; size_t LastOffset = 0; std::vector<pair<size_t, size_t>> Offsets; for (auto R : Occurences) { Position ShiftedStart = R.start - LastPos; size_t ShiftedStartOffset = positionToOffset(ShiftedStart, Code.substr(LastOffset); LastPos = ShiftedStart; LastOffset = ShiftedStartOffset; // Do the same for the end position. // ... } // Now we can easily replacements. // ... |
LGTM
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
453 | add assert(LastPos <= P) to protect against malformed inputs (e.g. if one of occurence ranges would have an endpoint that is before the starting point). | |
458 | NIT: braces are redundant and can be dropped. | |
459 | Could we simply propagate error? |
We are aiming to convert all ranges in O(n) instead of O(n^2), right?
I think this could be simpler and also have guaranteed performance even for long lines if we do it slightly differently. WDYT?