{"id":16936466,"url":"https://github.com/jonhoo/evmap","last_synced_at":"2025-05-15T20:05:35.719Z","repository":{"id":47814421,"uuid":"323200805","full_name":"jonhoo/evmap","owner":"jonhoo","description":"A lock-free, eventually consistent, concurrent multi-value map.","archived":false,"fork":false,"pushed_at":"2021-06-22T02:09:30.000Z","size":3777,"stargazers_count":504,"open_issues_count":6,"forks_count":16,"subscribers_count":6,"default_branch":"master","last_synced_at":"2025-05-15T01:49:08.259Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jonhoo.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE-APACHE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-12-21T01:26:52.000Z","updated_at":"2025-04-29T12:33:38.000Z","dependencies_parsed_at":"2022-09-26T21:20:48.727Z","dependency_job_id":null,"html_url":"https://github.com/jonhoo/evmap","commit_stats":null,"previous_names":[],"tags_count":55,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fevmap","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fevmap/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fevmap/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonhoo%2Fevmap/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jonhoo","download_url":"https://codeload.github.com/jonhoo/evmap/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254414499,"owners_count":22067272,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-13T20:57:02.964Z","updated_at":"2025-05-15T20:05:30.654Z","avatar_url":"https://github.com/jonhoo.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"[![Build Status](https://dev.azure.com/jonhoo/jonhoo/_apis/build/status/evmap?branchName=master)](https://dev.azure.com/jonhoo/jonhoo/_build/latest?definitionId=30\u0026branchName=master)\n[![Codecov](https://codecov.io/github/jonhoo/evmap/coverage.svg?branch=master)](https://codecov.io/gh/jonhoo/evmap)\n[![Crates.io](https://img.shields.io/crates/v/evmap.svg)](https://crates.io/crates/evmap)\n[![Documentation](https://docs.rs/evmap/badge.svg)](https://docs.rs/evmap/)\n\nA lock-free, eventually consistent, concurrent multi-value map.\n\nThis map implementation allows reads and writes to execute entirely in parallel, with no\nimplicit synchronization overhead. Reads never take locks on their critical path, and neither\ndo writes assuming there is a single writer (multi-writer is possible using a `Mutex`), which\nsignificantly improves performance under contention. It is backed by the\nconcurrency primitive [`left-right`](https://crates.io/crates/left-right).\n\nThe trade-off exposed by this module is one of eventual consistency: writes are not visible to\nreaders except following explicit synchronization. Specifically, readers only see the\noperations that preceeded the last call to `WriteHandle::flush` by a writer. This lets\nwriters decide how stale they are willing to let reads get. They can refresh the map after\nevery write to emulate a regular concurrent `HashMap`, or they can refresh only occasionally to\nreduce the synchronization overhead at the cost of stale reads.\n\nFor read-heavy workloads, the scheme used by this module is particularly useful. Writers can\nafford to refresh after every write, which provides up-to-date reads, and readers remain fast\nas they do not need to ever take locks.\n\nThe map is multi-value, meaning that every key maps to a *collection* of values. This\nintroduces some memory cost by adding a layer of indirection through a `Vec` for each value,\nbut enables more advanced use. This choice was made as it would not be possible to emulate such\nfunctionality on top of the semantics of this map (think about it -- what would the operational\nlog contain?).\n\nTo facilitate more advanced use-cases, each of the two maps also carry some customizeable\nmeta-information. The writers may update this at will, and when a refresh happens, the current\nmeta will also be made visible to readers. This could be useful, for example, to indicate what\ntime the refresh happened.\n\n## Performance\n\n**These benchmarks are outdated at this point, but communicate the right\npoint. Hopefully I'll have a chance to update them again some time\nsoon.**\n\nI've run some benchmarks of evmap against a standard Rust `HashMap` protected\nby a [reader-writer\nlock](https://doc.rust-lang.org/std/sync/struct.RwLock.html), as well as\nagainst [chashmap](https://crates.io/crates/chashmap) — a crate which provides\n\"concurrent hash maps, based on bucket-level multi-reader locks\". The\nbenchmarks were run using the binary in [benchmark/](benchmark/src/main.rs) on\na 40-core machine with Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz CPUs.\n\nThe benchmark runs a number of reader and writer threads in tight loops, each\nof which does a read or write to a random key in the map respectively. Results\nfor both uniform and skewed distributions are provided below. The benchmark\nmeasures the average number of reads and writes per second as the number of\nreaders and writers increases.\n\nPreliminary results show that `evmap` performs well under contention,\nespecially on the read side. This benchmark represents the worst-case usage of\n`evmap` in which every write also does a `refresh`. If the map is refreshed\nless often, performance increases (see bottom plot).\n\n![Read throughput](benchmark/read-throughput.png)\n![Write throughput](benchmark/write-throughput.png)\n![Write throughput](benchmark/write-with-refresh.png)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjonhoo%2Fevmap","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjonhoo%2Fevmap","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjonhoo%2Fevmap/lists"}