simdjson 0.3.0 → 0.4.0

data/vendor/simdjson/doc/implementation-selection.md

@@ -1,83 +0,0 @@
-CPU Architecture-Specific Implementations
-=========================================
-
-* [Overview](#overview)
-* [Runtime CPU Detection](#runtime-cpu-detection)
-* [Inspecting the Detected Implementation](#inspecting-the-detected-implementation)
-* [Querying Available Implementations](#querying-available-implementations)
-* [Manually Selecting the Implementation](#manually-selecting-the-implementation)
-
-Overview
---------
-
-The simdjson library takes advantage of SIMD instruction sets such as NEON, SSE and AVX to achieve
-much of its speed. Because these instruction sets work differently, simdjson has to compile a
-different version of the JSON parser for different CPU architectures, often with different
-algorithms to take better advantage of a given CPU!
-
-The current implementations are:
-* haswell: AVX2 (2013 Intel Haswell or later)
-* westmere: SSE4.2 (2010 Westmere or later).
-* arm64: 64-bit ARMv8-A NEON
-* fallback: A generic implementation that runs on any 64-bit processor.
-
-In many cases, you don't know where your compiled binary is going to run, so simdjson automatically
-compiles *all* the implementations into the executable. On Intel, it will include 3 implementations
-(haswell, westmere and fallback), and on ARM it will include 2 (arm64 and fallback).
-
-If you know more about where you're going to run and want to save the space, you can disable any of
-these implementations at compile time with `-DSIMDJSON_IMPLEMENTATION_X=0` (where X is HASWELL,
-WESTMERE, ARM64 and FALLBACK).
-
-The simdjson library automatically sets header flags for each implementation as it compiles; there
-is no need to set architecture-specific flags yourself (e.g., `-mavx2`, `/AVX2`  or
-`-march=haswell`), and it may even break runtime dispatch and your binaries will fail to run on
-older processors.
-
-Runtime CPU Detection
----------------------
-
-When you first use simdjson, it will detect the CPU you're running on, and swap over to the fastest
-implementation for it. This is a small, one-time cost and for many people will be paid the first
-time they call `parse()` or `load()`.
-
-Inspecting the Detected Implementation
---------------------------------------
-
-You can check what implementation is running with `active_implementation`:
-
-```c++
-cout << "simdjson v" << STRINGIFY(SIMDJSON_VERSION) << endl;
-cout << "Detected the best implementation for your machine: " << simdjson::active_implementation->name();
-cout << "(" << simdjson::active_implementation->description() << ")" << endl;
-```
-
-Implementation detection will happen in this case when you first call `name()`.
-
-Querying Available Implementations
-----------------------------------
-
-You can list all available implementations, regardless of which one was selected:
-
-```c++
-for (auto implementation : simdjson::available_implementations) {
-  cout << implementation->name() << ": " << implementation->description() << endl;
-}
-```
-
-And look them up by name:
-
-```c++
-cout << simdjson::available_implementations["fallback"]->description() << endl;
-```
-
-Manually Selecting the Implementation
--------------------------------------
-
-If you're trying to do performance tests or see how different implementations of simdjson run, you
-can select the CPU architecture yourself:
-
-```c++
-// Use the fallback implementation, even though my machine is fast enough for anything
-simdjson::active_implementation = simdjson::available_implementations["fallback"];
-```

data/vendor/simdjson/doc/parse_many.md

@@ -1,160 +0,0 @@
-parse_many
-==========
-
-An interface providing features to work with files or streams containing multiple JSON documents.
-As fast and convenient as possible.
-
-Contents
---------
-
-- [Motivations](#motivations)
-- [Performance](#performance)
-- [How it works](#how-it-works)
-- [Support](#support)
-- [API](#api)
-- [Use cases](#use-cases)
-
-Motivations
------------
-
-The main motivation for this piece of software is to achieve maximum speed and offer a
-better quality of life in parsing files containing multiple JSON documents.
-
-The JavaScript Object Notation (JSON) [RFC7159](https://tools.ietf.org/html/rfc7159) is a very handy
-serialization format.  However, when serializing a large sequence of
-values as an array, or a possibly indeterminate-length or never-
-ending sequence of values, JSON becomes difficult to work with.
-
-Consider a sequence of one million values, each possibly one kilobyte
-when encoded -- roughly one gigabyte.  It is often desirable to process such a dataset incrementally
-without having to first read all of it before beginning to produce results.
-
-Performance
------------
-
-Here is a chart comparing the speed of the different alternatives to parse a multiline JSON.
-The simdjson library provides a threaded and non-threaded parse_many() implementation.  As the
-figure below shows, if you can, use threads, but if you can't, it's still pretty fast!
-[![Chart.png](/doc/Multiline_JSON_Parse_Competition.png)](/doc/Multiline_JSON_Parse_Competition.png)
-
-How it works
-------------
-
-### Context
-
-The parsing in simdjson is divided into 2 stages.  First, in stage 1, we parse the document and find
-all the structural indexes (`{`, `}`, `]`, `[`, `,`, `"`, ...) and validate UTF8.  Then, in stage 2,
-we go through the document again and build the tape using structural indexes found during stage 1.
-Although stage 1 finds the structural indexes, it has no knowledge of the structure of the document
-nor does it know whether it parsed a valid document, multiple documents, or even if the document is
-complete.
-
-Prior to parse_many, most people who had to parse a multiline JSON file would proceed by reading the
-file line by line, using a utility function like `std::getline` or equivalent, and would then use
-the `parse` on each of those lines.  From a performance point of view, this process is highly
-inefficient,  in that it requires a lot of unnecessary memory allocation and makes use of the
-`getline` function, which is fundamentally slow, slower than the act of parsing with simdjson
-[(more on this here)](https://lemire.me/blog/2019/06/18/how-fast-is-getline-in-c/).
-
-Unlike the popular parser RapidJson, our DOM does not require the buffer once the parsing job is
-completed,  the DOM and the buffer are completely independent. The drawback of this architecture is
-that we need to allocate some additional memory to store our ParsedJson data, for every document
-inside a given file.  Memory allocation can be slow and become a bottleneck, therefore, we want to
-minimize it as much as possible.
-
-### Design
-
-To achieve a minimum amount of allocations, we opted for a design where we create only one
-parser object and therefore allocate its memory once, and then recycle it for every document in a
-given file. But, knowing that they often have largely varying size, we need to make sure that we
-allocate enough memory so that all the documents can fit. This value is what we call the batch size.
-As of right now, we need to manually specify a value for this batch size, it has to be at least as
-big as the biggest document in your file, but not too big so that it submerges the cached memory.
-The bigger the batch size, the fewer we need to make allocations. We found that 1MB is somewhat a
-sweet spot for now.
-
-1. When the user calls `parse_many`, we return a `document_stream` which the user can iterate over
-   to receive parsed documents.
-2. We call stage 1 on the first batch_size bytes of JSON in the buffer, detecting structural
-   indexes for all documents in that batch.
-3. We call stage 2 on the indexes, reading tokens until we reach the end of a valid document (i.e.
-   a single array, object, string, boolean, number or null).
-4. Each time the user calls `++` to read the next document, we call stage 2 to parse the next
-   document where we left off.
-5. When we reach the end of the batch, we call stage 1 on the next batch, starting from the end of
-   the last document, and go to step 3.
-
-### Threads
-
-But how can we make use of threads if they are available?  We found a pretty cool algorithm that allows us to quickly
-identify the  position of the last JSON document in a given batch. Knowing exactly where the end of
-the batch is, we no longer need for stage 2 to finish in order to load a new batch. We already know
-where to start the next batch. Therefore, we can run stage 1 on the next batch concurrently while
-the main thread is going through stage 2. Running stage 1 in a different thread can, in best
-cases, remove almost entirely its cost and replaces it by the overhead of a thread, which is orders
-of magnitude cheaper. Ain't that awesome!
-
-Thread support is only active if thread supported is detected in which case the macro
-SIMDJSON_THREADS_ENABLED is set. Otherwise the library runs in  single-thread mode.
-
-A `document_stream` instance uses at most two threads: there is a main thread and a worker thread.
-You should expect the main thread to be fully occupied while the worker thread is partially busy
-(e.g., 80% of the time).
-
-Support
--------
-
-Since we want to offer flexibility and not restrict ourselves to a specific file
-format, we support any file that contains any amount of valid JSON document, **separated by one
-or more character that is considered whitespace** by the JSON spec. Anything that is
- not whitespace will be parsed as a JSON document and could lead to failure.
-
-Whitespace Characters:
-- **Space**
-- **Linefeed**
-- **Carriage return**
-- **Horizontal tab**
-- **Nothing**
-
-Some official formats **(non-exhaustive list)**:
-- [Newline-Delimited JSON (NDJSON)](http://ndjson.org/)
-- [JSON lines (JSONL)](http://jsonlines.org/)
-- [Record separator-delimited JSON (RFC 7464)](https://tools.ietf.org/html/rfc7464) <- Not supported by JsonStream!
-- [More on Wikipedia...](https://en.wikipedia.org/wiki/JSON_streaming)
-
-API
----
-
-See [basics.md](basics.md#newline-delimited-json-ndjson-and-json-lines) for an overview of the API.
-
-## Use cases
-
-From [jsonlines.org](http://jsonlines.org/examples/):
-
-- **Better than CSV**
-    ```json
-    ["Name", "Session", "Score", "Completed"]
-    ["Gilbert", "2013", 24, true]
-    ["Alexa", "2013", 29, true]
-    ["May", "2012B", 14, false]
-    ["Deloise", "2012A", 19, true]
-    ```
-    CSV seems so easy that many programmers have written code to generate it themselves, and almost every implementation is
-    different. Handling broken CSV files is a common and frustrating task. CSV has no standard encoding, no standard column
-    separator and multiple character escaping standards. String is the only type supported for cell values, so some programs
-     attempt to guess the correct types.
-
-    JSON Lines handles tabular data cleanly and without ambiguity. Cells may use the standard JSON types.
-
-    The biggest missing piece is an import/export filter for popular spreadsheet programs so that non-programmers can use
-    this format.
-
-- **Easy Nested Data**
-    ```json
-    {"name": "Gilbert", "wins": [["straight", "7♣"], ["one pair", "10♥"]]}
-    {"name": "Alexa", "wins": [["two pair", "4♠"], ["two pair", "9♠"]]}
-    {"name": "May", "wins": []}
-    {"name": "Deloise", "wins": [["three of a kind", "5♣"]]}
-    ```
-    JSON Lines' biggest strength is in handling lots of similar nested data structures. One .jsonl file is easier to
-    work with than a directory full of XML files.

data/vendor/simdjson/doc/performance.md

@@ -1,172 +0,0 @@
-Performance Notes
-=================
-
-simdjson strives to be at its fastest *without tuning*, and generally achieves this. However, there
-are still some scenarios where tuning can enhance performance.
-
-* [Reusing the parser for maximum efficiency](#reusing-the-parser-for-maximum-efficiency)
-  * [Keeping documents around for longer](#keeping-documents-around-for-longer)
-* [Server Loops: Long-Running Processes and Memory Capacity](#server-loops-long-running-processes-and-memory-capacity)
-* [Large files and huge page support](#large-files-and-huge-page-support)
-* [Computed GOTOs](#computed-gotos)
-* [Number parsing](#number-parsing)
-* [Visual Studio](#visual-studio)
-* [Downclocking](#downclocking)
-
-
-Reusing the parser for maximum efficiency
------------------------------------------
-
-If you're using simdjson to parse multiple documents, or in a loop, you should make a parser once
-and reuse it. The simdjson library will allocate and retain internal buffers between parses, keeping
-buffers hot in cache and keeping memory allocation and initialization to a minimum. In this manner,
-you can parse terabytes of JSON data without doing any new allocation.
-
-```c++
-dom::parser parser;
-
-// This initializes buffers and a document big enough to handle this JSON.
-dom::element doc = parser.parse("[ true, false ]"_padded);
-cout << doc << endl;
-
-// This reuses the existing buffers, and reuses and *overwrites* the old document
-doc = parser.parse("[1, 2, 3]"_padded);
-cout << doc << endl;
-
-// This also reuses the existing buffers, and reuses and *overwrites* the old document
-dom::element doc2 = parser.parse("true"_padded);
-// Even if you keep the old reference around, doc and doc2 refer to the same document.
-cout << doc << endl;
-cout << doc2 << endl;
-```
-
-It's not just internal buffers though. The simdjson library reuses the document itself. The dom::element, dom::object and dom::array instances are *references* to the internal document.
-You are only *borrowing* the document from simdjson, which purposely reuses and overwrites it each
-time you call parse. This prevent wasteful and unnecessary memory allocation in 99% of cases where
-JSON is just read, used, and converted to native values or thrown away.
-
-> **You are only borrowing the document from the simdjson parser. Don't keep it long term!**
-
-This is key: don't keep the `document&`, `dom::element`, `dom::array`, `dom::object`
-or `string_view` objects you get back from the API. Convert them to C++ native values, structs and
-arrays that you own.
-
-Server Loops: Long-Running Processes and Memory Capacity
---------------------------------------------------------
-
-The simdjson library automatically expands its memory capacity when larger documents are parsed, so
-that you don't unexpectedly fail. In a short process that reads a bunch of files and then exits,
-this works pretty flawlessly.
-
-Server loops, though, are long-running processes that will keep the parser around forever. This
-means that if you encounter a really, really large document, simdjson will not resize back down.
-The simdjson library lets you adjust your allocation strategy to prevent your server from growing
-without bound:
-
-* You can set a *max capacity* when constructing a parser:
-
-  ```c++
-  dom::parser parser(1000*1000); // Never grow past documents > 1MB
-  for (web_request request : listen()) {
-    dom::element doc;
-    auto error = parser.parse(request.body).get(doc);
-    // If the document was above our limit, emit 413 = payload too large
-    if (error == CAPACITY) { request.respond(413); continue; }
-    // ...
-  }
-  ```
-
-  This parser will grow normally as it encounters larger documents, but will never pass 1MB.
-
-* You can set a *fixed capacity* that never grows, as well, which can be excellent for
-  predictability and reliability, since simdjson will never call malloc after startup!
-
-  ```c++
-  dom::parser parser(0); // This parser will refuse to automatically grow capacity
-  auto error = parser.allocate(1000*1000); // This allocates enough capacity to handle documents <= 1MB
-  if (error) { cerr << error << endl; exit(1); }
-
-  for (web_request request : listen()) {
-    dom::element doc;
-    error = parser.parse(request.body).get(doc);
-    // If the document was above our limit, emit 413 = payload too large
-    if (error == CAPACITY) { request.respond(413); continue; }
-    // ...
-  }
-  ```
-
-Large files and huge page support
----------------------------------
-
-There is a memory allocation performance cost the first time you process a large file (e.g. 100MB).
-Between the cost of allocation, the fact that the memory is not in cache, and the initial zeroing of
-memory, [on some systems, allocation runs far slower than parsing (e.g., 1.4GB/s)](https://lemire.me/blog/2020/01/14/how-fast-can-you-allocate-a-large-block-of-memory-in-c/). Reusing the parser mitigates this by
-paying the cost once, but does not eliminate it.
-
-In large file use cases, enabling transparent huge page allocation on the OS can help a lot. We
-haven't found the right way to do this on Windows or OS/X, but on Linux, you can enable transparent
-huge page allocation with a command like:
-
-```bash
-echo always > /sys/kernel/mm/transparent_hugepage/enabled
-```
-
-In general, when running benchmarks over large files, we recommend that you report performance
-numbers with and without huge pages if possible. Furthermore, you should amortize the parsing (e.g.,
-by parsing several large files) to distinguish the time spent parsing from the time spent allocating
-memory. If you are using the `parse` benchmarking tool provided with the simdjson library, you can
-use the `-H` flag to omit the memory allocation cost from the benchmark results.
-
-```
-./parse largefile # includes memory allocation cost
-./parse -H largefile # without memory allocation
-```
-
-Computed GOTOs
---------------
-
-For best performance, we use a technique called "computed goto" when the compiler supports it, it is
-also sometimes described as "Labels as Values". Though it is not part of the C++ standard, it is
-supported by many major compilers and it brings measurable performance benefits that are difficult
-to achieve otherwise. The computed gotos are  automatically disabled under Visual Studio.
-
-If you wish to forcefully disable computed gotos, you can do so by compiling the code with
-`-DSIMDJSON_NO_COMPUTED_GOTO=1`. It is not recommended to disable computed gotos if your compiler
-supports it. In fact, you should almost never need to be concerned with computed gotos.
-
-Number parsing
---------------
-
-Some JSON files contain many floating-point values. It is the case with many GeoJSON files. Accurately
-parsing decimal strings into binary floating-point values with proper rounding is challenging. To
-our knowledge, it is not possible, in general, to parse streams of numbers at gigabytes per second
-using a single core. While using the simdjson library, it is possible that you might be limited to a
-few hundred megabytes per second if your JSON documents are densely packed with floating-point values.
-
-
-- When possible, you should favor integer values written without a decimal point, as it simpler and faster to parse decimal integer values.
-- When serializing numbers, you should not use more digits than necessary: 17 digits is all that is needed to exactly represent double-precision floating-point numbers. Using many more digits than necessary will make your files larger and slower to parse.
-- When benchmarking parsing speeds, always report whether your JSON documents are made mostly of floating-point numbers when it is the case, since number parsing can then dominate the parsing time.
-
-
-Visual Studio
---------------
-
-On Intel and AMD Windows platforms, Microsoft Visual Studio enables programmers to build either 32-bit (x86) or 64-bit (x64) binaries. We urge you to always use 64-bit mode. Visual Studio 2019 should default on 64-bit builds when you have a 64-bit version of Windows, which we recommend.
-
-We do not recommend that you compile simdjson with architecture-specific flags such as  `arch:AVX2`. The simdjson library automatically selects the best execution kernel at runtime.
-
-Recent versions of Microsoft Visual Studio on Windows provides support for the LLVM Clang compiler. You  only need to install the "Clang compiler" optional component. You may also get a copy of the 64-bit LLVM CLang compiler for [Windows directly from LLVM](https://releases.llvm.org/download.html). The simdjson library fully supports the LLVM Clang compiler under Windows. In fact, you may get better performance out of simdjson with the LLVM Clang compiler than with the regular Visual Studio compiler.
-
-
-Downclocking
---------------
-
-You should not expect the simdjson library to cause downclocking of your recent Intel CPU cores.
-
-On some Intel processors, using SIMD instructions in a sustained manner on the same CPU core may result in a phenomenon called downclocking whereas the processor initially runs these instructions at a slow speed before reducing the frequency of the core for a short time (milliseconds). Intel refers to these states as licenses. On some current Intel processors, it occurs under two scenarios:
-
-- [Whenever 512-bit AVX-512 instructions are used](https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these-new-instructions/).
-- Whenever heavy 256-bit or wider instructions are used. Heavy instructions are those involving floating point operations or integer multiplications (since these execute on the floating point unit).
-
-The simdjson library does not currently support AVX-512 instructions and it does not make use of heavy 256-bit instructions. Thus there should be no downclocking due to simdjson on recent processors. You may still be worried about which SIMD instruction set is used by simdjson.  Thankfully,  [you can always determine and change which architecture-specific implementation is used](implementation-selection.md). Thus even if your CPU supports AVX2, you do not need to use AVX2. You are in control.

data/vendor/simdjson/doc/tape.md

@@ -1,136 +0,0 @@
-
-# Tape structure in simdjson 
-
-We parse a JSON document to a tape. A tape is an array of 64-bit values. Each node encountered in the JSON document is written to the tape using one or more 64-bit tape elements; the layout of the tape is in "document order": elements are stored as they are encountered in the JSON document. 
-
-Throughout, little endian encoding is assumed. The tape is indexed starting at 0 (the first element is at index 0).
-
-## Example
-
-It is sometimes useful to start with an example. Consider the following JSON document:
-
-```json
-{
-	"Image": {
-		"Width": 800,
-		"Height": 600,
-		"Title": "View from 15th Floor",
-		"Thumbnail": {
-			"Url": "http://www.example.com/image/481989943",
-			"Height": 125,
-			"Width": 100
-		},
-		"Animated": false,
-		"IDs": [116, 943, 234, 38793]
-	}
-}
-```
-
-The following is a dump of the content of the tape, with the first number of each line representing the index of a tape element.
-
-### The Tape
-| index | element (64 bit word)                                               |
-| ----- | ------------------------------------------------------------------- |
-| 0     | r	// pointing to 38 (right after last node)                         |
-| 1     | {	// pointing to next tape location 38 (first node after the scope) |
-| 2     | string "Image"                                                      |
-| 3     | {	// pointing to next tape location 37 (first node after the scope) |
-| 4     | string "Width"                                                      |
-| 5     | integer 800                                                         |
-| 7     | string "Height"                                                     |
-| 8     | integer 600                                                         |
-| 10    | string "Title"                                                      |
-| 11    | string "View from 15th Floor"                                       |
-| 12    | string "Thumbnail"                                                  |
-| 13    | {	// pointing to next tape location 23 (first node after the scope) |
-| 14    | string "Url"                                                        |
-| 15    | string "http://www.example.com/image/481989943"                     |
-| 16    | string "Height"                                                     |
-| 17    | integer 125                                                         |
-| 19    | string "Width"                                                      |
-| 20    | integer 100                                                         |
-| 22    | }	// pointing to previous tape location 13 (start of the scope)     |
-| 23    | string "Animated"                                                   |
-| 24    | false                                                               |
-| 25    | string "IDs"                                                        |
-| 26    | [	// pointing to next tape location 36 (first node after the scope) |
-| 27    | integer 116                                                         |
-| 29    | integer 943                                                         |
-| 31    | integer 234                                                         |
-| 33    | integer 38793                                                       |
-| 35    | ]	// pointing to previous tape location 26 (start of the scope)     |
-| 36    | }	// pointing to previous tape location 3 (start of the scope)      |
-| 37    | }	// pointing to previous tape location 1 (start of the scope)      |
-| 38    | r	// pointing to 0 (start root)                                     |
-
-
-
-## General formal of the tape elements
-
-Most tape elements are written as `('c' << 56) + x` where `'c'` is some ASCII character determining the type of the element (out of 't', 'f', 'n', 'l', 'u', 'd', '"', '{', '}', '[', ']' ,'r') and where `x` is a 56-bit value called the payload. The payload is normally interpreted as an unsigned 56-bit integer. Note that 56-bit integers can be quite large.
-
-
-Performance consideration: We believe that accessing the tape in regular units of 64 bits is more important for performance than saving memory. 
-
-## Simple JSON values
-
-Simple JSON nodes are represented with one tape element:
-
-- null is  represented as the 64-bit value `('n' << 56)` where `'n'` is the 8-bit code point values (in ASCII) corresponding to the letter `'n'`.
-- true is  represented as the 64-bit value `('t' << 56)`.
-- false is  represented as the 64-bit value `('f' << 56)`.
-
-
-## Integer and Double values
-
-Integer values are represented as two 64-bit tape elements:
-- The 64-bit value `('l' << 56)` followed by the 64-bit integer value literally. Integer values are assumed to be signed 64-bit values, using two's complement notation.
-- The 64-bit value `('u' << 56)` followed by the 64-bit integer value literally. Integer values are assumed to be unsigned 64-bit values.
-
-
-Float values are represented as two 64-bit tape elements:
-- The 64-bit value `('d' << 56)` followed by the 64-bit double value literally in standard IEEE 754 notation.
-
-Performance consideration: We store numbers of the main tape because we believe that locality of reference is helpful for performance. 
-
-## Root node
-
-Each JSON document will have two special 64-bit tape elements representing a root node, one at the beginning and one at the end.
-
-- The first 64-bit tape element contains the value `('r' << 56) + x` where `x` is the location on the tape of the last root element.
-- The last 64-bit tape element contains the value `('r' << 56)`.
-
-All of the parsed document is located between these two 64-bit tape elements.
-
-Hint: We can read the first tape element to determine the length of the tape.
-
-
-## Strings
-
-We prefix the string data itself by a 32-bit header to be interpreted as a 32-bit integer. It indicates the length of the string. The actual string data starts at an offset of 4 bytes.
-
-We store string values using UTF-8 encoding with null termination on a separate tape. A string value is represented on the main tape as the 64-bit tape element `('"' << 56) + x` where the payload `x` is the location on the string tape of the null-terminated string. 
-
-## Arrays 
-
-JSON arrays are represented using two 64-bit tape elements.
-
-- The first 64-bit tape element contains the value `('[' << 56) + x` where the payload `x` is 1 + the index of the second 64-bit tape element on the tape. 
-- The second 64-bit tape element contains the value `(']' << 56) + x` where the payload `x` contains the index of the first 64-bit tape element on the tape.
-
-All the content of the array is located between these two tape elements, including arrays and objects.
-
-Performance consideration: We can skip the content of an array entirely by accessing the first 64-bit tape element, reading the payload and moving to the corresponding index on the tape.
-
-## Objects 
-
-JSON objects are represented using two 64-bit tape elements.
-
-- The first 64-bit tape element contains the value `('{' << 56) + x` where the payload `x` is 1 + the index of the second 64-bit tape element on the tape.
-- The second 64-bit tape element contains the value `('}' << 56) + x` where the payload `x` contains the index of the first 64-bit tape element on the tape.
-
-In-between these two tape elements, we alternate between key (which must be strings) and values. A value could be an object or an array.
-
-All the content of the object is located between these two tape elements, including arrays and objects. 
-
-Performance consideration: We can skip the content of an object entirely by accessing the first 64-bit tape element, reading the payload and moving to the corresponding index on the tape.