7 unstable releases

0.4.0 Mar 7, 2024
0.3.1 Nov 27, 2023
0.3.0 May 16, 2023
0.2.2 Apr 17, 2023
0.1.0 Oct 15, 2022

#28 in Caching

Download history 1417/week @ 2024-07-19 1105/week @ 2024-07-26 1253/week @ 2024-08-02 1185/week @ 2024-08-09 1292/week @ 2024-08-16 1416/week @ 2024-08-23 1554/week @ 2024-08-30 1446/week @ 2024-09-06 1357/week @ 2024-09-13 1811/week @ 2024-09-20 1829/week @ 2024-09-27 1888/week @ 2024-10-04 1736/week @ 2024-10-11 2790/week @ 2024-10-18 1940/week @ 2024-10-25 2135/week @ 2024-11-01

8,844 downloads per month
Used in 39 crates (25 directly)

MIT/Apache

47KB
890 lines

comemo

Crates.io Documentation

Incremental computation through constrained memoization.

[dependencies]
comemo = "0.4"

A memoized function caches its return values so that it only needs to be executed once per set of unique arguments. This makes for a great optimization tool. However, basic memoization is rather limited. For more advanced use cases like incremental compilers, it lacks the necessary granularity. Consider, for example, the case of the simple .calc scripting language. Scripts in this language consist of a sum of numbers and eval statements that reference other .calc scripts. A few examples are:

  • alpha.calc: "2 + eval beta.calc"
  • beta.calc: "2 + 3"
  • gamma.calc: "8 + 3"

We can easily write an interpreter that computes the output of a .calc file:

/// Evaluate a `.calc` script.
fn evaluate(script: &str, files: &Files) -> i32 {
    script
        .split('+')
        .map(str::trim)
        .map(|part| match part.strip_prefix("eval ") {
            Some(path) => evaluate(&files.read(path), files),
            None => part.parse::<i32>().unwrap(),
        })
        .sum()
}

impl Files {
    /// Read a file from storage.
    fn read(&self, path: &str) -> String {
        ...
    }
}

But what if we want to make this interpreter incremental, meaning that it only recomputes a script's result if it or any of its dependencies change? Basic memoization won't help us with this because the interpreter needs the whole set of files as input—meaning that a change to any file invalidates all memoized results.

This is where comemo comes into play. It implements constrained memoization with more fine-grained access tracking. To use it, we can just:

  • Add the #[memoize] attribute to the evaluate function.
  • Add the #[track] attribute to the impl block of Files.
  • Wrap the files argument in comemo's Tracked container.

This instructs comemo to memoize the evaluation and to automatically track all file accesses during a memoized call. As a result, we can reuse the result of a .calc script evaluation as long as its dependencies stay the same—even if other files change.

use comemo::{memoize, track, Tracked};

/// Evaluate a `.calc` script.
#[memoize]
fn evaluate(script: &str, files: Tracked<Files>) -> i32 {
    ...
}

#[track]
impl Files {
    /// Read a file from storage.
    fn read(&self, path: &str) -> String {
        ...
    }
}

For the full example see examples/calc.rs.

License

This crate is dual-licensed under the MIT and Apache 2.0 licenses.

Dependencies

~0.7–6MB
~29K SLoC