From 6f01030c4e6b27027ddd015807c3c5e5694cd5b1 Mon Sep 17 00:00:00 2001 From: Niels Lohmann Date: Mon, 9 Nov 2026 11:37:52 +0100 Subject: [PATCH] docs: fix json_view links in the 3.13.0 performance blog post (#6044) #6018 split features/json_view.md into features/json_view/ sub-pages while #6022 added a blog post linking to the old page, so `mkdocs build --strict` failed on develop (Publish documentation run 42577793091). Point the links to json_view/index.md and json_view/editing.md. Signed-off-by: Niels Lohmann --- docs/mkdocs/docs/home/blog/how_3_13_0_got_faster.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/mkdocs/docs/home/blog/how_3_13_0_got_faster.md b/docs/mkdocs/docs/home/blog/how_3_13_0_got_faster.md index 7f6417e38..64d54ac82 100644 --- a/docs/mkdocs/docs/home/blog/how_3_13_0_got_faster.md +++ b/docs/mkdocs/docs/home/blog/how_3_13_0_got_faster.md @@ -22,7 +22,7 @@ Since 2016, the [README](https://github.com/nlohmann/json#readme) of this librar That sentence is still true, but the gap is a lot smaller now. Swap the 3.12.0 header for the 3.13.0 one, recompile, and the 182 benchmarks of the library's own suite run 3.0× as fast on an Apple M1 Max (geometric mean; 3.1× on an Intel MacBook Pro from 2016). Not a line of your code changes. Parsing typical documents got 3.1–4.3× as fast, and writing -them 3.0–6.7×. The new version also adds [`json_document`](../../features/json_view.md), a second way to hold a parsed +them 3.0–6.7×. The new version also adds [`json_document`](../../features/json_view/index.md), a second way to hold a parsed document, which competes with the fastest C++ and Rust JSON libraries; [How it compares](#how-it-compares) has the numbers, including where it loses. The price is compile time: two small example programs take 34–62% longer to compile. A precompiled header or a C++20 module wins back most or all of that in debug builds, and 41–91% of it in optimized @@ -397,7 +397,7 @@ runs one word first. Inlining the vector code into the lexer cost 5% of validati no string of that file is long enough to reach it: the scan function, which runs once per token, saved more registers and needed a stack slot. -[`json_document`](../../features/json_view.md), the new document type of `json_view.hpp`, also skips the digits after a +[`json_document`](../../features/json_view/index.md), the new document type of `json_view.hpp`, also skips the digits after a decimal point 16 bytes at a time with SSE2: a compare and a bit mask instead of a branch per digit, about 33% of the instructions for a 12-digit fraction. Parsing `canada.json` got 22% faster on x86-64, a file of 10,000 floats 28–32%. @@ -1132,7 +1132,7 @@ million small objects 1.39×. After all of the above, [`json::parse()`](../../api/basic_json/parse.md) is still bound by what it builds: one heap allocation per string, array and object, and a `std::map` node per member, all of which have to be freed again. Many programs only parse a document, read some fields and throw it away, or change a few values and write it back. For them, -3.13.0 adds [`json_document`](../../features/json_view.md) and `json_view` in a new header, ``. +3.13.0 adds [`json_document`](../../features/json_view/index.md) and `json_view` in a new header, ``. The two figures below show what each parser makes of this 54-byte text: ```json @@ -1215,7 +1215,7 @@ static_assert(sizeof(node) == 16, "node must stay 16 bytes"); ### It can be edited, too A read-only index is the easy case, and a fair objection is that `json_document` is only fast because it can't change. -[`json_editable_document`](../../features/json_view.md#editing-a-document) has `set()`, `insert()`, `erase()` and +[`json_editable_document`](../../features/json_view/editing.md) has `set()`, `insert()`, `erase()` and `push_back()`. An edit never writes into the source text and never moves the parsed index: - a new scalar is written over its own node, with new string and number text in an append-only arena;