Conversation
| nodes: FxHashSet<GreenNode>, | ||
| tokens: FxHashSet<GreenToken>, | ||
| nodes: HashMap<GreenNode, ()>, | ||
| tokens: HashMap<GreenToken, ()>, |
There was a problem hiding this comment.
Are these HashMap just because of drain_filter?
There was a problem hiding this comment.
Yes (unfortunately).
A further optimization step in the pipeline will take further advantage of HashMap::raw_entry_mut, so the switch to using set-like maps is probably inevitable, though.
|
What is the effect on peak memory usage for analysis stats using rust analyzer? |
|
It's not going to have an immediate impact because r-a doesn't (IIUC) yet hold on to or reuse node caches. Additionally, it will only potentially have an impact when holding onto a node cache after the deletion of a parse tree. We aren't really generating any garbage to clean up; it's only useful if the cache outlives the tree(s) that it's built. |
|
is this still valid? |
Originally implemented in sorbus here: CAD97/sorbus#46
Also exposes the
NodeCache(closes #53) so that the gc is usable. WhileGreenNodeBuilderhas hadwith_cachefor a while, it's been impossible to actually share the cache, as there was no way to get a cache to share!