Implement new allocator and support garbage collection #4994
Assignees
Labels
compiler: frontend
Everything to do with type checking, control flow analysis, and everything between parsing and IRgen
enhancement
New feature or request
Comments
tritao
added
enhancement
|
Hey @tritao just wondering which slot map crate you tried already that gave you those results? |
|
I think it was this one: https://docs.rs/slotmap/latest/slotmap/ |
7 tasks
JoshuaBatty
added a commit
that referenced
this issue
Nov 10, 2023
## Description This PR supersedes #4988 and builds on backend work done by @tritao in #4733. A new `ModuleId` is created for each compiled module. The `SourceId` type now also stores the `ModuleId` that was used to create it. This allows us to perform garbage collection on types in the Declaration and Type engines that refer the provided module. ```rust if let Some(module_id) = engines.se().get_module_id(&path) { engines.clear_module(&module_id); } ``` This method isn't super cheap to call. My tests had this averaging at 54ms. We are currently performing garbage collection on every key stroke in LSP. We should look to have another metric such as only clearing once every 20 keystrokes or so in the future. I ran benchmarking on recompiling the `doc_comments` example 20 times to simulate rapid keystrokes during coding. Here are the results. | Without Caching | With Caching | |---------------------|------------------| | 89.489 s | 4.6236 s | A speed up of 1835.49% is certainly great, yet 4.6 seconds still sounds like an eternity. Still have lots of room to improve but this should improve our current system dramatically. closes #4994 Co-authored-by: Joao Matos <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For supporting long-term compilation sessions (for LSP use) we want to support garbage collecting the engines.
Right now this is not possible due to our current slab allocator not supporting removing previously allocated ids.
We should re-implement the slab allocator using either an optimized slot map, or the buddy allocator algorithm.
(Tests using a slotmap crate based implementation proved to be 15-20% slower than the current allocator.)
Additionally we can move to a multiple allocator model, where we setup a slab per module, and allow cross-linking of type/decl ids.
This will also allow for easier incremental compilation as well as less transient caching due to a more straight forward cache serialization.
The text was updated successfully, but these errors were encountered: