[sient]

I tried using rtags before developing cquery, but found it did not perform well enough for Chrome when doing a huge number of semantic operations (I was hacking in support for code lens). I spent some time trying to figure out if it code be fixed but I believe it would have been too large of an architectural change.

- cquery interacts with an editor via the language server protocol, letting it work with any editor with relatively minimal work - cquery handles larger repositories better (ie, indexing all of Chrome takes 20-30 minutes on a high-end workstation) - cquery responds to semantic requests within 10ms or so

There are some other differences but those are related to the features implemented, ie, cquery supports code lens.

I'm not sure how code completion is in rtags, but I've spent a fair amount of time making it work as fast as possible in cquery. There is quite a bit of caching built on-top of the clang API which often makes it feel instantaneous.

[qyron]

I've been happy user of ycmd+rtags tandem for a couple of years. A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too). This allows me to do develop on my weak 4-core laptop and offload indexing to fast 32-core workstation.

Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (RecursiveASTVisitor etc.), so IMHO any difference in indexing time between rtags and cquery should come from such factors as number of parsing threads, database for storing tags, caching etc.

Anyway I'm really excited about cquery and even consider moving to VSCode just because of it (being a long-term VIM user). Reliable "Find references" feature is (IMHO) a must-have functionality for large codebases and currently (thanks to cquery and rtags) is supported much better in modern C++ than in other system languages (such as Go and Rust).

[sient]

> A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too).

I have a similar use case in mind, so I'm planning on trying to get this working by writing a simple script that proxies language server messages over SSH/TCP. Ideally it should work with any language server.

> Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (RecursiveASTVisitor etc.), so IMHO any difference in indexing time between rtags and cquery should come from such factors as number of parsing threads, database for storing tags, caching etc.

Yea, it is amazing how big of a difference the architecture around indexing makes - any sort of global lock/shared state really hurts performance. I spent a significant amount of time finding the right architecture to make each index job as independent as possible. Most of the design decisions in cquery are oriented towards either latency or throughput at the cost of things like memory and total system load (I've since reduced memory usage, but at one point cquery used 30gb after indexing Chrome - now it is around 5gb).

> Anyway I'm really excited about cquery and even consider moving to VSCode just because of it (being a long-term VIM user). Reliable "Find references" feature is (IMHO) a must-have functionality for large codebases and currently (thanks to cquery and rtags) is supported much better in modern C++ than in other system languages (such as Go and Rust).

I'd like to see cquery support in vim as well using a vim LSP implementation :). But yes, I agree with you - cquery makes me want to continue using C++ over Rust simply because the tooling works a lot better.