Merge pull request #231 from cuviper/release-1.9.0

Release 1.9.0 with backports from master

.github/workflows/ci.yml

@@ -16,7 +16,7 @@ jobs:
     strategy:
       matrix:
         include:
-          - rust: 1.49.0 # MSRV
+          - rust: 1.56.1 # MSRV
             features:
           - rust: stable
             features: serde
@@ -59,7 +59,7 @@ jobs:
     strategy:
       matrix:
         include:
-          - rust: 1.49.0
+          - rust: 1.56.1
             target: thumbv6m-none-eabi
           - rust: stable
             target: thumbv6m-none-eabi

.rustfmt.toml

@@ -1 +1 @@
-edition = "2018"
+edition = "2021"

Cargo.toml

@@ -1,37 +1,21 @@
 [package]
 name = "indexmap"
-edition = "2018"
-version = "1.8.2"
-authors = [
-"bluss",
-"Josh Stone <[email protected]>"
-]
+edition = "2021"
+version = "1.9.0"
 documentation = "https://docs.rs/indexmap/"
 repository = "https://github.com/bluss/indexmap"
-license = "Apache-2.0/MIT"
-description = """
-A hash table with consistent order and fast iteration.
-
-The indexmap is a hash table where the iteration order of the key-value
-pairs is independent of the hash values of the keys. It has the usual
-hash table functionality, it preserves insertion order except after
-removals, and it allows lookup of its elements by either hash table key
-or numerical index. A corresponding hash set type is also provided.
-
-This crate was initially published under the name ordermap, but it was renamed to
-indexmap.
-"""
-
+license = "Apache-2.0 OR MIT"
+description = "A hash table with consistent order and fast iteration."
 keywords = ["hashmap", "no_std"]
 categories = ["data-structures", "no-std"]
-
-build = "build.rs"
+rust-version = "1.56.1"
 
 [lib]
 bench = false
 
 [build-dependencies]
 autocfg = "1"
+
 [dependencies]
 serde = { version = "1.0", optional = true, default-features = false }
 rayon = { version = "1.4.1", optional = true }
@@ -41,7 +25,7 @@ rayon = { version = "1.4.1", optional = true }
 rustc-rayon = { version = "0.4", optional = true }
 
 [dependencies.hashbrown]
-version = "0.11"
+version = "0.12"
 default-features = false
 features = ["raw"]
 

README.md

@@ -0,0 +1,55 @@
+# indexmap
+
+[![build status](https://github.com/bluss/indexmap/workflows/Continuous%20integration/badge.svg?branch=master)](https://github.com/bluss/indexmap/actions)
+[![crates.io](https://img.shields.io/crates/v/indexmap.svg)](https://crates.io/crates/indexmap)
+[![docs](https://docs.rs/indexmap/badge.svg)](https://docs.rs/indexmap)
+[![rustc](https://img.shields.io/badge/rust-1.56.1%2B-orange.svg)](https://img.shields.io/badge/rust-1.56.1%2B-orange.svg)
+
+A pure-Rust hash table which preserves (in a limited sense) insertion order.
+
+This crate implements compact map and set data-structures,
+where the iteration order of the keys is independent from their hash or
+value. It preserves insertion order (except after removals), and it
+allows lookup of entries by either hash table key or numerical index.
+
+Note: this crate was originally released under the name `ordermap`,
+but it was renamed to `indexmap` to better reflect its features.
+
+# Background
+
+This was inspired by Python 3.6's new dict implementation (which remembers
+the insertion order and is fast to iterate, and is compact in memory).
+
+Some of those features were translated to Rust, and some were not. The result
+was indexmap, a hash table that has following properties:
+
+- Order is **independent of hash function** and hash values of keys.
+- Fast to iterate.
+- Indexed in compact space.
+- Preserves insertion order **as long** as you don't call `.remove()`.
+- Uses hashbrown for the inner table, just like Rust's libstd `HashMap` does.
+
+## Performance
+
+`IndexMap` derives a couple of performance facts directly from how it is constructed,
+which is roughly:
+
+> A raw hash table of key-value indices, and a vector of key-value pairs.
+
+- Iteration is very fast since it is on the dense key-values.
+- Removal is fast since it moves memory areas only in the table,
+  and uses a single swap in the vector.
+- Lookup is fast-ish because the initial 7-bit hash lookup uses SIMD, and indices are
+  densely stored. Lookup also is slow-ish since the actual key-value pairs are stored
+  separately. (Visible when cpu caches size is limiting.)
+
+- In practice, `IndexMap` has been tested out as the hashmap in rustc in [PR45282] and
+  the performance was roughly on par across the whole workload.
+- If you want the properties of `IndexMap`, or its strongest performance points
+  fits your workload, it might be the best hash table implementation.
+
+[PR45282]: https://github.com/rust-lang/rust/pull/45282
+
+# Recent Changes
+
+See [RELEASES.md](https://github.com/bluss/indexmap/blob/master/README.md).