wasm compatibility - change Expiry to avoid needing std::time::Instant::now()

[lorepozo]

When creating a new moka::sync::Cache on wasm32-unknown-unknown, a panic results: time is not implemented on this platform. This is because std::time::Instant::now() is being called.

moka already has a quanta feature which uses its version of Instant that supports wasm32-unknown-unknown. But despite that feature being enabled, std::time::Instant is also used.

It appears necessary because of the pub trait Expiry which provides configurable behavior based on std::time::Instant: current_time and last_modified_at. That means resolving this issue — enabling moka::sync::Cache on wasm — requires a breaking change to the API.

The Expiry trait could be changed as follows: current_time is generally unnecessary as the implementation can do it if desired, and last_modified_at may instead be something like duration_since_modified. E.g.:

fn expire_after_read(
    &self,
    key: &K,
    value: &V,
                                              // no longer provided: `current_time`
    duration_until_expiry: Option<Duration>,  // renamed from `current_duration`
    duration_since_modified: Duration         // subsumes `last_modified_at`
) -> Option<Duration>

[tatsuya6502]

Hi. Thank you for the idea! Unfortunately, there is another feature request to expose the metadata of cached entries; many of the values in the metadata are std::time::Instant.

• Provide a way to iterate entries with their metadata #312

I am not sure what to do (yet), but maybe we will add a crate feature, and when it is enabled, use quanta::Instant in the API where std::time::Instant is used?

[tatsuya6502]

By the way, if you do not need Expiry, you could use v0.10.4 until we found a solution for the std::time::Instant issue. (v0.10.x does not have Expiry) We are still back-porting important bug fixes to v0.9.x, v0.10.x and v0.11.x.

A while ago, I was able to build and run very basic stuff for wasm32-unknown-unknown target using v0.9.4: #173 (comment). However we made no progress after that.

[tatsuya6502]

I do not have enough knowledge and experience in wasm to make a good decision on this, but I think moka would not be a good choice for a product that runs on wasm32-unknown-unknown target.

moka has the following downsides when used in a wasm target:

• Large and complex code base, which is necessary to provide the best performance and convenient features for concurrent programing.
  • However, multi-threading support is not generally available on wasm32-unknown-unknown target today.
  • The large code base will produce a large wasm binary to download.
• High memory overhead, which might be necessary to provide the best performance for concurrent programming.
  • (I think the available memory will be limited in environments like web browsers)
  • It has large multi-producer single-consumer channels as buffers, to apply changes in a batch to avoid lock contentions. These buffers are not needed for single-thread program.
  • It uses Arc to share data between threads. An Arc itself only adds a small memory overhead. However, the cache can use a large number of Arcs when having many cached entries, so the overhead could be significant.
  • It uses doubly linked list for the LRU and other cache policies. While they are helping to realize high hit rate, it is not as memory efficent as other data structures like pseudo-LRUs.

Have you checked other crates that provide smaller feature sets?

https://lib.rs/caching

You may want to check the following crates:

• lru
• quick_cache
• mini-moka (mini_moka::unsync::Cache)

and maybe you want to tell us what features are missing from mini-moka for your project.

[tatsuya6502]

Closing as there are no activities. Feel free to reopen if needed.