Rust Glancer, 분석 결과를 디스크에 보존해 Rust LSP 메모리 사용량 100MB 미만 목표

이 프로젝트 저자는 내가 아니라 popzxc임. 나는 별도 글로 생각을 적었는데, 이 주제는 프로젝트 자체로 스레드가 서는 편이 맞다고 봄.

나는 당장은 지연 로딩보다 분석 품질을 먼저 개선하려 함. 지금은 열린 버퍼를 먼저 처리하고 나머지는 백그라운드에서 인덱싱하며, RustRover는 아직 안 써봤지만 비교해볼 생각임.

나는 약어를 설명하지 않는 글이 답답함. Rust LSP가 뭔지 처음 보는 사람도 있을 텐데 말임.

LSP는 VS Code 같은 IDE가 린팅, 문법 검사, 정의나 참조 이동을 하려고 쓰는 Language Server Protocol임.

나는 독자가 예상되는 분야 용어는 굳이 다 풀어쓸 필요 없다고 봄. Rust와 LSP는 프로그래머 사이에서 널리 쓰는 말임.

큰 워크스페이스에서 rust-analyzer가 메모리 내 구조를 다 만들 때까지 기다리는 건 고통스러움. RustRover는 다르다는 얘기를 들었는데, 실제 사용 경험과 단점이 궁금함.

나는 이걸 rust-analyzer의 디스크 캐시 버전으로 이해했음.

디스크에 두고 필요할 때만 읽는다는 큰 발상은 비슷하지만, rust-analyzer에 캐시를 붙인 구조는 아님.

Rust에는 명세가 없는데, LSP가 올바른 정보를 준다는 건 어떻게 검증하는지 궁금함.

증분 방식은 필요한 것만 처리하니 메모리를 덜 쓸 것 같은데, 왜 더 많이 쓰는지 설명이 더 필요함. 전체 분석 스냅샷을 디스크에 저장하고 필요할 때 읽는다면 결국 워크스페이스 최대 메모리를 쓰는 것 아닌가 싶음.

나는 Neovim에서 LSP를 쓰면 RAM을 너무 많이 먹는 경우가 많아서 이 프로젝트를 써보고 싶음.

rust-analyzer가 인스턴스당 2GiB를 먹는 건 부담임. 디스크 캐시를 거부하면 인덱싱 최적화 압박은 유지되겠지만, 요즘 RAM 가격과 병렬 작업 환경에서는 잘못된 우선순위라고 봄.

나는 rust-analyzer가 내 24GiB 시스템에서 가장 큰 프로세스인 경우가 많아도, 메모리 절감 때문에 개발 도구의 사용성이 나빠지는 건 걱정됨. Rust 도구가 아주 좋아서, 메모리 최적화보다 편의성에 투자하는 시도도 지지함.