[PATCH] D87891: [clangd] findNearbyIdentifier(): guaranteed to give up after 2^N lines
Aleksandr Platonov via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Sep 24 00:44:23 PDT 2020
ArcsinX added a comment.
In D87891#2291760 <https://reviews.llvm.org/D87891#2291760>, @kadircet wrote:
> The biggest problem I see is, this is not changing the fact that we are still traversing the whole file:
>
> - You do one traversal over the whole file to find `FileLines`
> - Then possibly two more to find `OffsetMin` and `OffsetMax`
Seems you are right, but we do not compare strings during traversal to find `FileLines`.
> You can get rid of the first one by just using `getLocForEndOfFile` if `positionToOffset` fails.
> For the latter, you can use `SourceManager::translateLineCol` instead, it uses a cache and cheaper than the linear scan performed by `positionToOffset` in case of multiple calls. The cache is already populated once we issue the first `Cost` call, through `SM.getSpellingLineNumber`
>
> I was reluctant overall as the wins aren't clear. We are still going to traverse the whole file at least once, and readability is hindered but I suppose with the above mentioned two trics, runtime shouldn't be regressed.
> Also it is nice to get rid of 2 log calls for each token. Again all of these feels like some micro optimizations that aren't justified.
Thanks for your reply, I will rethink this patch.
================
Comment at: clang-tools-extra/clangd/XRefs.cpp:568
if (Line < WordLine)
- return 2 + llvm::Log2_64(WordLine - Line);
+ return 2 + WordLine - Line;
return 0;
----------------
sammccall wrote:
> this has changed the relative ordering, if we're dropping the log then +1 should now become multiplication by two.
> (Or was this intended?)
Yes, you are right, my fault here.
But should we penalize backwards so hard?
================
Comment at: clang-tools-extra/clangd/XRefs.cpp:580
return false;
- // No point guessing the same location we started with.
- if (Tok.location() == Word.Location)
----------------
sammccall wrote:
> why can't this happen anymore?
As I understand, we call `findNearbyIdentifier()` only when the word is not an identifier. And `Tok` is always identifier here.
Btw, even if `findNearbyIdentifier()` could be called for an identifier, I could not get why it's bad to return current position here.
Am I wrong?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D87891/new/
https://reviews.llvm.org/D87891
More information about the cfe-commits
mailing list