deploy: ad94fb01cc

api/ordered_map.md

@@ -56,6 +56,48 @@ std::equal_to<>     // since C++14
 - **find**
 - **insert**
 
+## Complexity
+
+Because the elements are stored in a `std::vector` in insertion order, there is no index to look a key up by. Every
+key-based operation performs a **linear scan** over the stored elements. With `n` denoting the number of elements in the
+container:
+
+| Operation                              | Complexity     | Note                                                     |
+|----------------------------------------|----------------|----------------------------------------------------------|
+| **emplace**                            | O(n)           | scans for an existing key, then appends (amortized O(1)) |
+| **operator\[\]**                       | O(n)           | delegates to **emplace** (non-const) or **at** (const)   |
+| **at**                                 | O(n)           | throws `#!cpp std::out_of_range` if the key is not found |
+| **find**                               | O(n)           |                                                          |
+| **count**                              | O(n)           | the result is always 0 or 1                              |
+| **erase(key)**                         | O(n)           | scan, then move the remaining elements one position down |
+| **erase(pos)**, **erase(first, last)** | O(n)           | moves all elements after the erased range                |
+| **insert(value)**                      | O(n)           | equivalent to **emplace**                                |
+| **insert(first, last)**                | O((n + m) * m) | for `m` inserted elements                                |
+
+This differs from `#!cpp std::map`, where the same operations are O(log n).
+
+!!! warning "Quadratic cost of building large objects"
+
+    Because every insertion scans all elements inserted so far, building an object of `n` distinct keys costs
+    **O(n²)** in total. This applies to filling an [`ordered_json`](ordered_json.md) object key by key as well as to
+    parsing one, since the parser inserts each key as it is read.
+
+    The cost is negligible for the object sizes typically found in configuration files or API payloads, but it grows
+    steeply for machine-generated objects with many thousands of keys. Measured with `-O2 -DNDEBUG` for parsing a flat
+    object of `n` keys, relative to `#!cpp nlohmann::json` (which uses `#!cpp std::map`):
+
+    | `n`    | `json` | `ordered_json` | factor |
+    |--------|--------|----------------|--------|
+    | 2000   | 0.7 ms | 3.6 ms         | 5×     |
+    | 4000   | 0.8 ms | 14.0 ms        | 19×    |
+    | 8000   | 1.6 ms | 67.8 ms        | 43×    |
+    | 16 000 | 3.3 ms | 181.6 ms       | 54×    |
+
+    If key order matters for objects of that size, consider a container with a lookup index, such as
+    [`tsl::ordered_map`](https://github.com/Tessil/ordered-map)
+    ([integration](https://github.com/nlohmann/json/issues/546#issuecomment-304447518)), as the object type -- see
+    [object order](../features/object_order.md).
+
 ## Examples
 
 ??? example