Feature/inc cache propagation #1220
Conversation
dpl0a
force-pushed
the
feature/IncCache-propagation
branch
from
df97144 to
152993b
Compare
dpl0a
force-pushed
the
feature/IncCache-propagation
branch
from
152993b to
17031c9
Compare
There was a problem hiding this comment.
I'm in for merging this soon and not letting this PR stale, however, it adds non trivial changes, including in the main codebase. I think it really needs more documentation and comments, if we want to be able to understand what's going on a few months from now.
Beside, I wonder if we might also update Thunk::saturate to work "in-place", now that we revert everything in advance anyway. But that's not very important for this PR, I'm just thinking out loud.
| fn smart_clone(&mut self, v: Vec<CacheIndex>) -> HashMap<CacheIndex, CacheIndex>; | ||
|
|
||
| fn propagate_dirty(&mut self, indices: Vec<CacheIndex>); |
There was a problem hiding this comment.
We need to document those functions, even just a draft, waiting for more. Those are the cornerstones of incremental evaluation, and are now used inside merge.
| @@ -370,4 +314,67 @@ impl Cache for IncCache { | |||
| RichTerm::from(Term::App(partial_app, arg)) | |||
| }) | |||
| } | |||
|
|
|||
| fn smart_clone(&mut self, v: Vec<CacheIndex>) -> HashMap<CacheIndex, CacheIndex> { | |||
There was a problem hiding this comment.
this functions need comments inside
|
I ran the benchmarks locally, and changes are within the noise threshold (not in the sense of criterion, which shows +- 5 to 10% depending on the benchmarks, but that's unfortunately something common, which is also observed across run of the same benchmarks on the same branch). The mantis benchmark seemed to take a small hit, but the numbers are volatile enough so that it doesn't seem to be a huge effect. |
This PR implements part of the
IncCacheinterface for incremental merging and modifies some functions related to merging records.