deploy: cdfb130fa6
This commit is contained in:
1 parent
8ddeea7128
commit
5097c20962
516 files changed
+7306
-5984
No files matched your search
@@ -13,7 +13,7 @@ For inputs backed by contiguous, single-byte memory — a `std::string`, a `std:
|
||||
- it can reconstruct already-consumed input on demand for error messages, instead of copying every character as it is read, and
|
||||
- the lexer can scan ordinary string characters, numbers, and indentation directly out of the buffer, several bytes at a time, rather than one character (and one function call) at a time.
|
||||
|
||||
A `std::istream` (including `std::ifstream`) gets the same bulk scanning: `input_stream_adapter` scans the characters its stream buffer already holds (the *get area*) and asks the stream buffer for more only when they are used up. Nothing is read ahead, so the stream is left exactly where it would be after reading one character at a time, and [`operator>>`](https://json.nlohmann.me/api/operator_gtgt/index.md) can still read several values from one stream. A stream buffer without a get area is read one character at a time. A `FILE*` is locked once per parse instead of once per character, and with glibc and the Apple C library, the characters in its buffer are scanned in bulk as a stream's get area is. See [input sources and performance](https://json.nlohmann.me/features/parsing/#input-sources-and-performance) for the full table. Parsing from a stream takes about 1.15 to 1.45 times as long as parsing an equivalent `std::string`, which `parse()` reads with a parser of its own (see there).
|
||||
A `std::istream` (including `std::ifstream`) gets the same bulk scanning: `input_stream_adapter` scans the characters its stream buffer already holds (the *get area*) and asks the stream buffer for more only when they are used up. Nothing is read ahead, so the stream is left exactly where it would be after reading one character at a time, and [`operator>>`](https://json.nlohmann.me/api/operator_gtgt/index.md) can still read several values from one stream. A stream buffer without a get area is read one character at a time. Where the C library has unlocked stdio functions, a `FILE*` is locked once per parse instead of once per character, and with glibc and the Apple C library, the characters in its buffer are scanned in bulk as a stream's get area is. [`JSON_DISABLE_STREAM_BULK_SCAN`](https://json.nlohmann.me/api/macros/json_disable_stream_bulk_scan/index.md) turns off the bulk scan of streams, and [`JSON_DISABLE_UNLOCKED_FILE_IO`](https://json.nlohmann.me/api/macros/json_disable_unlocked_file_io/index.md) both the single lock and the bulk scan of a `FILE*`. See [input sources and performance](https://json.nlohmann.me/features/parsing/#input-sources-and-performance) for the full table. Parsing from a stream takes about 1.15 to 1.45 times as long as parsing an equivalent `std::string`, which `parse()` reads with a parser of its own (see there).
|
||||
|
||||
Inputs that are still read one character at a time: iterator ranges that are not contiguous (e.g. `std::list<char>` or `std::istreambuf_iterator<char>`), wide strings, and user-defined adapters. An iterator pair over non-contiguous but random-access storage (e.g. `std::deque<char>::iterator`) gets the first optimization but not the second, since the byte-scanning fast path requires contiguous storage.
|
||||
|
||||
|
||||
Reference in new issue
Block a user