Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Glancer: Rust LSP using 100x less RAM

rust-glancer.github.io

Post reply on HN
Print view View original

91–100 of 129 posts

Re: Rust Glancer: Rust LSP using 100x less RAM

#91

Post by popzxc »

avianlyric wrote: post #68
dbdr wrote: post #66

Earlier quoted context omitted.

Oh, if peak RAM usage is higher, in which scenario do you find that's a significant gain? Maybe I misunderstood, what I got from the blog post is that there will be indexing on save (vs on each keystroke with RA). That would be often enough that lower RAM enough in between would not be of much gain. Is that only an incremental indexing with normally low RAM usage? So you would essentially fully index only once per pr…

It looks like it only partially reindexes on save, but it completely reindexes the single file that’s saved, rather than doing partial reindex of the file on every keystroke like rust-analyser. But importantly it’s not reindexing the entire project, which is the expensive operation. So you have higher peak RAM when opening a brand new project, but much lower RAM usage while working on the project.

Exactly. You pay higher RAM usage price once, for 5-30 seconds at the very beginning of the project (or if you make changes that invalidate the dependency graph, which is rather rare). In 95% of cases and 99.999% of idle time using the editor, you enjoy lower RAM usage.

And note that on dirty buffers Rust Glancer doesn't do reindexing at all: it reuses the last available analysis, plus it does syntax-based shallow overlay that is sufficient to be useful but doesn't necessarily detect semantic changes. It's a tradeoff, but this tradeoff makes Rust Glancer competitive in terms of latency with rust-analyzer without compromising RAM and while keeping your CPU cool.

> it completely reindexes the single file that’s saved

This is true, though I have to mention that change in the file might invalidate its reverse dependencies, which can make the partial analysis bigger than just one file/crate, but it's still very fast in practice.

Re: Rust Glancer: Rust LSP using 100x less RAM

#92

Post by popzxc »

dbdr wrote: post #66
popzxc wrote: post #48

Earlier quoted context omitted.

I will work on creating a more or less fair benchmark soon-ish, but right now the initial indexing typically consumes more RAM than rust analyzer does, but not awfully so. The difference, however, is that with Rust Glancer you don’t need full reindexing often, so it probably compensates for that to a degree.

Oh, if peak RAM usage is higher, in which scenario do you find that's a significant gain? Maybe I misunderstood, what I got from the blog post is that there will be indexing on save (vs on each keystroke with RA). That would be often enough that lower RAM enough in between would not be of much gain. Is that only an incremental indexing with normally low RAM usage? So you would essentially fully index only once per pr…

> So you would essentially fully index only once per project, + whenever you upgrade dependencies or upgrade rustc?

This is when you do full reindexing.

> Is that only an incremental indexing with normally low RAM usage?

Yup, on save you only update the crates that were invalidated.

Re: Rust Glancer: Rust LSP using 100x less RAM

#93

Post by tombert »

popzxc wrote: post #90
tombert wrote: post #88

Tangential, but I've found something LLMs are actually ridiculously good at is making LSP servers. I couldn't find good TLA+ bindings for Neovim, so I got Claude to hack together an LSP server for it [1]. It works shockingly well, and it only took about an hour of arguing with Claude to do it. I find it's not terribly good at actually writing TLA+ (with some very recent tests with Fable), so I'm not completely useles…

I would say that LLMs have really good understanding of LSPs, but they are not necessarily good at building them. Had I blindly followed the proposed flow, Rust Glancer wouldn't have reached a stage where it is at least remotely usable. At some point the size of the project becomes too big for LLM to fit in its context window, and with the tendence to add code rather than remove, the bloat can explode really quickly.…

I don't think I disagree with any of that.

TLA+ is a relatively simple language so I think it's a good candidate for this kind of stuff; most of the stuff in the generated LSP also just proxies straight to the official command line tools. It's certainly a simpler language than Rust, so I think it's easier for Claude to keep a higher percentage of stuff in context, and at least using the TLA+ bindings seems to work pretty well.

I haven't done it since my laptop has lots of RAM, but I suspect that I will likely edit the generated code to eat less at some point.

Re: Rust Glancer: Rust LSP using 100x less RAM

#95

Post by MeetingsBrowser »

maxlin wrote: post #80

Good work, though can't help but think that when something that isn't just a small hack where perf doesn't matter can be made "100x faster", it tells more about the original work than the new thing :D

Not 100x faster, but 100x less memory. In fact, this version is actually slower for some use cases.

Everything is a trade off.

Re: Rust Glancer: Rust LSP using 100x less RAM

#96

Post by jmalicki »

popzxc wrote: post #90
tombert wrote: post #88

Tangential, but I've found something LLMs are actually ridiculously good at is making LSP servers. I couldn't find good TLA+ bindings for Neovim, so I got Claude to hack together an LSP server for it [1]. It works shockingly well, and it only took about an hour of arguing with Claude to do it. I find it's not terribly good at actually writing TLA+ (with some very recent tests with Fable), so I'm not completely useles…

I would say that LLMs have really good understanding of LSPs, but they are not necessarily good at building them. Had I blindly followed the proposed flow, Rust Glancer wouldn't have reached a stage where it is at least remotely usable. At some point the size of the project becomes too big for LLM to fit in its context window, and with the tendence to add code rather than remove, the bloat can explode really quickly.…

> At some point the size of the project becomes too big for LLM to fit in its context window, and with the tendence to add code rather than remove, the bloat can explode really quickly.

While it's certainly worse with LLMs, humans, especially teams of humans, have the same issue. This is where being good with software architecture is a superpower for working with LLMs, since good separation of concerns and modularity help this immensely. LLMs can even often do this themselves if you are very harsh and critical about this in design review stages, but it requires the skill to be able to recognize it and to have a "vision" for the software architecture.

Re: Rust Glancer: Rust LSP using 100x less RAM

#97

Post by popzxc »

jmalicki wrote: post #96
popzxc wrote: post #90

Earlier quoted context omitted.

I would say that LLMs have really good understanding of LSPs, but they are not necessarily good at building them. Had I blindly followed the proposed flow, Rust Glancer wouldn't have reached a stage where it is at least remotely usable. At some point the size of the project becomes too big for LLM to fit in its context window, and with the tendence to add code rather than remove, the bloat can explode really quickly.…

> At some point the size of the project becomes too big for LLM to fit in its context window, and with the tendence to add code rather than remove, the bloat can explode really quickly. While it's certainly worse with LLMs, humans, especially teams of humans, have the same issue. This is where being good with software architecture is a superpower for working with LLMs, since good separation of concerns and modularity…

Yup. Basically, I have been combining both a manager and IC role for years now, which certainly helps working with LLMs: I can "delegate", and I know when to "intervene". It certainly is a skill, but the issue with LLMs is the confident voice you hear at the end of the turn: "the task is done, all is good"; and given that LLMs tend to praise its own code and tend to avoid global architecture reworks (I guess it's a training artifact), you need to understand the situation and resist hearing "nah, the architecture is fine, the rework is too much of work" phrased very convincingly. It's kind of peer pressure combined with both authority and glazing, which is a weirdly deceptive (to the point of being manipulative) mix.

I certainly enjoy working with humans much more than working with LLMs. Working with humans is usually "how can we get this done together", while working with LLMs is pretty much is "how can I make this model do what I need", which is something I don't like. An personal persistent thought I have now is not to transfer my relationship with LLMs to my relationship with human beings, and I don't really like it.

Re: Rust Glancer: Rust LSP using 100x less RAM

#100

Post by bigstrat2003 »

762236 wrote: post #9
IshKebab wrote: post #6

Earlier quoted context omitted.

LSP is a well known term among programmers these days.

Not if an LLM writes your code. I get thousands of lines of high quality Rust per day without ever stepping into VScode.

So you're not a programmer, and therefore aren't part of the audience for a programming tool.
Post reply on HN