Hacker News Reader

Comment by macqm | Hacker News Reader

>Because of this huge codebase size, I wasn't able to get VS Code's C++ extension to work very well with the project. Features like go-to definition (which I usually rely on heavily when navigating codebases) and find references didn't work well or at all, and one of my CPU cores would stay stuck at 100% permanently while the project was open.

Chromium Code Search [1] tool is very helpful with that and I believe there are some extensions that integrate with it.

1: https://source.chromium.org/chromium/chromium/src

View on HN

It's also possible to get go-to-definition etc working in VSCode locally. You need to switch from Microsoft's C++ extension to the clangd extension. Clangd scales better and is more accurate for projects using clang like Chromium. Instructions here: https://chromium.googlesource.com/chromium/src.git/+/HEAD/do...

The Chromium code search site is still very useful too.

I've been working on an extension https://github.com/phil294/search-plus-plus-vscode-extension for instant search results in gigantic repos like this one because it's a recurring pattern that bothers me. And eventually I'd like it to use its index to provide full go-to, autocomplete etc. on a pure plain text basis, because why not? I don't get the obsession with full-fledged language integration when plain text-based search results can get you all the way 9 out of 10 times, whereas a typical language plugin will constantly suffer from brokenness, performance problems and general annoyance, unless maybe you're working in pure JS/TS. And while LSP is great, you still have to fight this battle separately for every language you use. And regular "search" features are dreadful too.

It's one of these things that Jetbrains products are vastly superior in. It's fast, always works, falls back to text matching and also natively allows multiple languages per source file.

Sounds really interesting, and useful for most developers. I think the issue is probably more what people have read about edge cases, than what it's actually like to use an extension like you are building. People tend to worry that they will hit the edge case and not realize it, so completely avoid anything that might give them faster results in the name of 100% accuracy that they will probably never hit. In a typed language, I would think that it would be extremely rare to search and make the type of changes that would be missed in that edge case, and the code still compiles without issue. Maybe I just haven't worked on large enough codebases, or ones that are full of "magic" where such a thing would create such an issue.

Regardless, I think it's impressive that you've taken on this task and are sharing it with the VSCode community, and appreciate you sharing.

For Visual Studio on Windows Google provides a search extension that indexes Chromium locally and gives instant results for search. I was always puzzled why such functionality is not available in most IDE by default.

Is it something similar to ctags? https://github.com/universal-ctags/ctags

BTW there also exists the same code search tool for Android (AOSP): https://cs.android.com

I use it all the time as an Android app developer. Its introduction was a big deal, because before that, it was common among Android developers to pull AOSP sources (all the many gigabytes of them) to one's local machine and just grep around.

Oh yeah, Code Search is good.

it is not as good as the search built into Azure Devops [1] however. You don't know power search until you've used a search tool built on the backs of the devs of Windows. Being able to say "Uhhhh I know it was a macro called DeBeanIt2k near a comment with "HACK" in it" gets turned into "comment:HACK macro:DeBeanIt2k" and you get answers back is super nice. There's also an API for it.

1: https://learn.microsoft.com/en-us/azure/devops/project/searc...

First, thank you for sharing this helpful link, but LOL at needing to use a third party server to search plain text data that could fit in RAM (at least on this developer's machine). JavaScript- and JSON-based developer tooling is a terrible idea.

I'm sure it can do a plaintext search just fine. What the author is talking about is language-aware features like "go to definition". Holding all of a whole web browser's C++ parsing tree in memory is a lot bigger ask than just its plain text.

You're assuming that the only way to a definition of an identifier is 1) parse the entire source tree 2) keep the entire source tree in memory 3) use that in-memory source tree to go to definition. If you accept those constraints and then implement in a slow language, then yes, it won't work.

You’re rather underestimating the vast expanse that is the Chromium codebase, I think. That said, distributing tags files was a common thing once, and a dedicated symbol package you could just download and feed into your language server (instead of being constantly tethered to a symbol server) could make for a nice affordance today.

So this actually exists, as it turns out. You can run clangd-indexer to produce a static index and then load it with clangd -index-file. The caveat is that

> [r]unning clangd-indexer is expensive and produced index is not incremental.

It's not searching plaintext though.

VSCode itself can deal with big text data being thrown at it, this will be some of the language server stuff

I'm glad VSCode handles large text files better for you than it does for me. Editing anything large in VSCode makes it slow to a crawl on my machines.

Interesting.

The only time I had problems was very big JSONs with everything on one line, but prettifying fixed that. (Or was it XML? I forgot. One of those.)

Reply on news.ycombinator.com