Izstrādātājs ar segvārdu popzxc 19. augustā publicēja Rust Glancer, alternatīvu Rust valodas LSP serveri. Tas izanalizēto darbtelpu glabā diskā un dīkstāvē patērē mazāk par 100 MB operatīvās atmiņas. Autora paša darba vidē rust-analyzer aizņēma 16 GB.
Tie 16 GB nav tipisks rādītājs. popzxc raksta, ka viņam uz diviem monitoriem ir atvērti divi vienādi VS Code logi ar vairākiem projektiem katrā, tāpēc patēriņš dubultojas. Parastam lietotājam ar vienu redaktoru rēķins ir mazāks, bet joprojām mērāms gigabaitos. Rust Glancer mērķis ir zem 100 MB arī lieliem projektiem.
Kur rust-analyzer atmiņa aiziet
popzxc nosauc trīs iemeslus. Pirmais ir pati Rust darbtelpa. Tajā ir tūkstošiem funkciju, struktūru un tipu ieviešanu, sakarības starp tām, funkciju ķermeņi ar visiem izteikumiem. Bez šo datu indeksēšanas nestrādā tāda pamatlieta kā “atrast visas atsauces uz šo struktūru”.
Otrais iemesls ir salsa, inkrementālā vaicājumu datubāze, uz kuras rust-analyzer ir uzbūvēts. Tā rēķina slinki un iegaumē starprezultātus, lai nākamajā taustiņsitienā pārrēķinātu tikai to, kas mainījies. Šis modelis ir piesiets atmiņai. Daļu datu izcelt uz diska ir grūti, jo datubāze pati neparedz, kas kurā brīdī būs vajadzīgs.
Trešais ir rowan, sintakses koka bibliotēka. Tā ļauj pārparsēt tikai izmainīto faila daļu, kas ir ātri, taču koka struktūra atmiņu sadrumstalo. No operētājsistēmas paņemtais apjoms sanāk lielāks par faktiski izmantoto.
Sasaldēta darbtelpa diska vietā atmiņā
Rust Glancer no inkrementalitātes atsakās. Indeksēšana notiek uzreiz un pilnā apjomā. Rezultāts nokļūst failu sistēmā. Atmiņā to ielādē tikai uz viena LSP vaicājuma izpildes laiku.
No tā izriet divas lietas. Dīkstāvē process gandrīz neko neaizņem. Un, ja projekts reiz ir indeksēts, redaktora pārstartēšana pēc tam darbtelpu atjauno gandrīz acumirklī, jo neko pārrēķināt nevajag.
Cena par to ir divējāda. Vaicājumi vidēji izpildās lēnāk, jo nolasīšana un deserializācija no diska prasa vairāk laika par piekļuvi atmiņai. Autors šo laiku novērtē kā pieņemamu cilvēka uztverei: papildinājumu saraksts parādās simtos milisekunžu.
Otra cena ir manāmāka ikdienā. Kamēr lietotājs raksta, Rust Glancer veic tikai seklu pašreizējā ķermeņa analīzi un izmanto iepriekšējo pilno indeksu. Jauni importi, struktūras un tipi indeksā nonāk tikai pēc faila saglabāšanas. Autors apgalvo, ka tam pierod ātri.
Atsevišķi apstrādāta ir situācija, kad kodu maina AI aģents ārpus redaktora. popzxc raksta, ka rust-analyzer šādos gadījumos inlay hints izšķobījās. Tāpēc Rust Glancer ir savs failu novērotājs. Ārpus redaktora veiktām izmaiņām serveris piešķir zemāku prioritāti, lai aģenta darbs nesāktu nepārtrauktu pārindeksēšanu.
Atmiņas fragmentāciju popzxc apkaro ar diviem paņēmieniem. Piešķīrumu dzīves ciklus viņš saskaņo tā, lai īslaicīgie objekti tiktu atbrīvoti kopā. Katra darbtelpa strādā savā apakšprocesā, kas vienlaikus atrisina arī otru problēmu: ja vienā VS Code darbtelpā ir vairāki Rust projekti un vienam no tiem analīze nobrūk, pārējie turpina strādāt. Indeksēšana nesākas, kamēr projekts nav atvērts.
Indeksēšanas etaloni
popzxc publicēja mērījumus uz divām mašīnām. Uz 2020. gada MacBook Pro M1 ar 8 GB atmiņas Rust Glancer bāzes indeksēšanu pabeidz 6 sekundēs, pilno 9 sekundēs. rust-analyzer tajā pašā datorā prasa 7 un 14 sekundes. Uz 2025. gada MacBook Pro M4 Max ar 36 GB skaitļi ir 5 un 8 sekundes pret rust-analyzer 6 un 13 sekundēm.
Salīdzinājums nav pilnīgi līdzvērtīgs. Rust Glancer procedurālos makro neatbalsta vispār, bet tieši to izvēršana rust-analyzer sākotnējo indeksēšanu velk visgarāko.
Skaitļus autors nemēra ar roku. Vienā no pirmajām nedēļām viņš uzbūvēja profilēšanas rīkus, kas seko gan faktiski piešķirtajiem objektiem, gan jemalloc statistikai. Tie paši rīki salīdzina rezultātu ar rust-analyzer. Etaloni darbojas CI. popzxc raksta, ka bez šīs infrastruktūras projekts būtu miris ātri, jo atmiņas regresijas citādi paliktu nepamanītas līdz brīdim, kad tās vairs nav izsekojamas.
Ko tas vēl neprot
Repozitorija apraksts mērķi formulē kā 90 % pilnības, ar to saprotot “pietiekami ikdienas darbam”. Strādā pāreja uz definīciju, hover, inlay hints un papildinājumi. Nav procedurālo makro, būvēšanas skriptu izpildes un jebkā cita, kas prasītu palaist neuzticamu kodu. Tipu izsecināšana dažos gadījumos kļūdās. Deklaratīvos makro autors izvērš, pārņemot rust-analyzer infrastruktūru.
GitHub repozitorijā ir 416 commit un 202 zvaigznes. Projekts ir divkārši licencēts ar Apache 2.0 un MIT. README ir atsevišķa sadaļa par LLM lietojumu: popzxc raksta, ka modeļus izmanto daudz, kodu uzskata par savu un tā lasāmībai velta daudz laika.
Ko saka rust-analyzer aizsācējs
Aleksejs Kladovs, kurš rust-analyzer uzsāka un ir pazīstams kā matklad, 21. augustā projektu nosauca par neticami foršu un izmantoja to par ieganstu kritizēt paša aizsākto arhitektūru. Viņaprāt, rust-analyzer ir tikai zirga priekšējā puse.
Pārējiem projekta failiem PSI būtu jābalsta uz kompaktu diska attēlojumu, kas glabā tikai ārēji redzamās daļas, raksta Kladovs. Vienkāršāko ieguvumu viņš saskata rustc jau ģenerētajos
.rmetafailos, kurus rust-analyzer atkarībām varētu lasīt salsa vietā.
Kladovs piekrīt arī tam, ka procedurālo makro atbalsts rust-analyzer uzpūta. Pēc viņa atmiņām, aptuveni 30 % binārā faila izmēra bija JSON parsēšanas kods.
Pats popzxc gaida, ka rust-analyzer paliks noklusējuma izvēle projektiem, kuriem svarīga pilnība un precizitāte uz katru taustiņsitienu. Rust Glancer viņš adresē vājākām mašīnām. Uz savas 2020. gada M1 ar 8 GB viņš to izmēģināja un raksta, ka bija pietiekami labi. Par galveno rīku savā darbā viņš to lieto aptuveni pusotru mēnesi.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.