Repository navigation
Conversation
nlohmann
added this pull request to stack #5636
September 29, 2026 14:20
Owner
Author
|
CI fixes for this PR (commits fa58c6e and 448c9dd, plus the lower fixes merged in). CI had not run yet, so these were found locally with the CI's compilers:
Verified with — posted by Claude Code on behalf of @nlohmann |
nlohmann
removed this pull request from stack #5636
September 30, 2026 13:19
nlohmann
force-pushed
the
json-view/16-view-simd
branch
from
September 30, 2026 13:20
50f0a1b to
d33586c
Compare
nlohmann
force-pushed
the
json-view/18-view-object-index
branch
from
September 30, 2026 13:20
448c9dd to
0f6438a
Compare
nlohmann
added this pull request to stack #5739
September 30, 2026 13:21
nlohmann
force-pushed
the
json-view/16-view-simd
branch
from
September 30, 2026 15:34
d33586c to
6f43699
Compare
nlohmann
force-pushed
the
json-view/18-view-object-index
branch
3 times, most recently
from
September 30, 2026 18:06
fc025bb to
b02a0bd
Compare
nlohmann
marked this pull request as ready for review
September 30, 2026 18:16
Lookups in objects are linear, as for ordered_json. Objects with 128 members or more now get a hash table after parsing (open addressing; the first of duplicate keys is kept, as for the linear search), so that operator[], at(), find(), contains(), count(), value(), and JSON pointers take constant time on average in them; the idea of switching to a hash table for large objects is Boost.JSON's. The parser notes such objects when it closes them (out of line, so that the parse loop only has a call for it), and the object node keeps the number of its table. Looking up each key of an object with 10,000 members: 59.8 ms -> 0.16 ms. Parsing (json_document::parse, best of 7, separate processes): most files within 1%; canada +5%, mesh.pretty +3%, citm +3%. Tests: objects with 127, 128, 129, and 10,000 members (escaped, empty, and duplicate keys, missing keys, comparisons), nested large objects, and documents reused with read(). Signed-off-by: Niels Lohmann <mail@nlohmann.me>
Signed-off-by: Niels Lohmann <mail@nlohmann.me>
The node index section says what extra holds for objects and how large objects are indexed. Signed-off-by: Niels Lohmann <mail@nlohmann.me>
GCC -Werror=useless-cast on Linux x86-64 rejects static_cast<std::size_t>(key_hash(...)): the call returns a std::uint64_t prvalue, the same type as std::size_t there, while the cast is needed where std::size_t is 32 bits wide. Store the hash in a variable and cast that, which GCC does not report. Signed-off-by: Niels Lohmann <mail@nlohmann.me>
With the nested struct object_index, clang 4 (and, by the same bug, the clang 3.x of ci_test_compilers_clang) rejects the explicitly noexcept defaulted constructor: "default member initializer for 'indexes' needed within definition of enclosing class 'document_data' outside of member functions". Nothing depends on the constructor being noexcept, so let it take the implicit exception specification. Signed-off-by: Niels Lohmann <mail@nlohmann.me>
nlohmann
force-pushed
the
json-view/16-view-simd
branch
from
September 30, 2026 19:19
d4ac1b7 to
1f0c3be
Compare
nlohmann
force-pushed
the
json-view/18-view-object-index
branch
from
September 30, 2026 19:19
b02a0bd to
eede67c
Compare
…ndex Signed-off-by: Niels Lohmann <mail@nlohmann.me>
…ndex Signed-off-by: Niels Lohmann <mail@nlohmann.me>
…ndex Signed-off-by: Niels Lohmann <mail@nlohmann.me>
Signed-off-by: Niels Lohmann <mail@nlohmann.me>
nlohmann
removed this pull request from stack #5739
October 6, 2026 09:26
Owner
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the stack for the zero-copy view (#5295).
Summary
Lookups in objects are linear, as for
ordered_json. Objects with 128 members or more now get a hash table after parsing:operator[],at(),find(),contains(),count(),value(), and JSON pointers take constant time on average in such objects.The idea of switching to a hash table for large objects comes from Boost.JSON.
The parser notes a large object when it closes it. This happens out of line, so the parse loop only has a call for it; done inline, it made canada.json 37% slower. The object node keeps the number of its table.
The node index section of the architecture page describes the tables and what
extraholds for objects.Benchmarks
json_document::parse, best of 7, separate processes): most files within 1%; canada +5%, mesh.pretty +3%, citm +3%.Tests
read().Public API
No change (faster lookups).
Written by Claude Code.
🤖 Generated with Claude Code