{"id":51103319,"url":"https://github.com/fastserial/lite3","last_synced_at":"2026-06-24T14:00:29.863Z","repository":{"id":325163097,"uuid":"1099814886","full_name":"fastserial/lite3","owner":"fastserial","description":"A JSON-Compatible Zero-Copy Serialization Format","archived":false,"fork":false,"pushed_at":"2026-03-20T23:42:39.000Z","size":1146,"stargazers_count":777,"open_issues_count":5,"forks_count":31,"subscribers_count":6,"default_branch":"main","last_synced_at":"2026-03-21T14:44:24.470Z","etag":null,"topics":["binary","c","json","schemaless","serialization","serialization-format","serialization-library","zero-copy"],"latest_commit_sha":null,"homepage":"https://lite3.io","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/fastserial.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-11-19T13:32:04.000Z","updated_at":"2026-03-20T23:42:42.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/fastserial/lite3","commit_stats":null,"previous_names":["fastserial/lite3"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/fastserial/lite3","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fastserial%2Flite3","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fastserial%2Flite3/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fastserial%2Flite3/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fastserial%2Flite3/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/fastserial","download_url":"https://codeload.github.com/fastserial/lite3/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/fastserial%2Flite3/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34735266,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-24T02:00:07.484Z","response_time":106,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["binary","c","json","schemaless","serialization","serialization-format","serialization-library","zero-copy"],"created_at":"2026-06-24T13:00:17.530Z","updated_at":"2026-06-24T14:00:29.849Z","avatar_url":"https://github.com/fastserial.png","language":"C","funding_links":[],"categories":["Capabilities"],"sub_categories":["Serialization"],"readme":"# Lite³: A JSON-Compatible Zero-Copy Serialization Format\r\n*Parse no more—the wire format is the memory format.*\r\n\r\n![](img/lite3_landing_page.png)\r\n![](img/lite3_infographic_dark.png)\r\n\r\n\u003ch2\u003e\u003ca href=\"https://lite3.io/\"\u003eOfficial Documentation (with examples): lite3.io\u003c/a\u003e\u003c/h2\u003e\r\n\u003ch4\u003e\u003ca href=\"https://lite3.io/design_and_limitations.html\"\u003eRead more about the design of Lite³\u003c/a\u003e\u003c/h4\u003e\r\n\r\n\r\n## Introduction\r\nLite³ is a zero-copy binary serialization format encoding data as a B-tree inside a single contiguous buffer, allowing access and mutation on any arbitrary field in `O(log n)` time. Essentially, it functions as a *serialized dictionary*. \r\n\r\nAs a result, the serialization boundary has been broken: 'parsing' or 'serializing' in the traditional sense is no longer necessary. Lite³ structures can be read and mutated directly similar to hashmaps or binary trees, and since they exist in a single contiguous buffer, they always remain ready to send.\r\n\r\nCompared to other binary formats, Lite³ is schemaless, self-describing (no IDL or schema definitions required) and **supports conversion to/from JSON**, enabling compatibility with existing datasets/APIs and allowing for easy debugging/inspecting of messages.\r\n\r\nThanks to the cache-friendly properties of the B-tree and the very minimalistic C implementation (9.3 kB), Lite³ outperforms the fastest JSON libraries (that make use of SIMD) by up to 120x depending on the benchmark. It also outperforms schema-only formats, such as Google Flatbuffers (242x). Lite³ is possibly the fastest schemaless data format in the world.\r\n\r\nExample to illustrate:\r\n1. A Lite³ message is received from a socket\r\n2. Without doing any parsing, the user can immediately:\r\n    - Lookup keys and read values via zero-copy pointers\r\n    - Insert/overwrite arbitrary key/value entries\r\n3. After all operations are done, the structure can be transmitted 'as-is' (no serialization required, just `memcpy()`)\r\n4. The receiver then has access to all the same operations\r\n\r\nTypically, in such a scenario a distinct 'serializing' and 'deserializing' step would be required.\r\nHowever Lite³ blurs the line between memory and wire formats, allowing direct access, traversal and mutation of a serialized buffer.\r\n\r\n\r\n## Features\r\n- Schemaless \u0026 self-describing, no IDL or schema definitions required\r\n- Zero-copy reads + writes of any data size\r\n- Lives on OSI layer 6 (transport/protocol agnostic)\r\n- O(log n) amortized time complexity for all IOPS\r\n- Built-in pointer validation\r\n- Low memory profile\r\n- Predictable latency\r\n- No `malloc()` API, caller provides buffer\r\n- Library size 9.3 kB (core) and dependency-free\r\n- Written in C11 using GNU C syntax\r\n- Optional subdependency (yyjson) to support conversion to/from JSON\r\n- MIT license\r\n\r\n\r\n## Code Example\r\n(error handling omitted for brevity)\r\n```C\r\n#include \u003cstdio.h\u003e\r\n#include \u003cstdbool.h\u003e\r\n\r\n#include \"lite3.h\"\r\n\r\n\r\nuint8_t buf[1024];\r\n\r\n\r\nint main() {\r\n    size_t buflen = 0;\r\n    size_t bufsz = sizeof(buf);\r\n\r\n    lite3_init_obj(buf, \u0026buflen, bufsz);\r\n    lite3_set_str(buf, \u0026buflen, 0, bufsz, \"app_name\", \"demo_app\");\r\n    lite3_set_i64(buf, \u0026buflen, 0, bufsz, \"max_retries\", 3);\r\n    lite3_set_bool(buf, \u0026buflen, 0, bufsz, \"debug_mode\", false);\r\n\r\n    int64_t max_retries;\r\n    lite3_get_i64(buf, buflen, 0, \"max_retries\", \u0026max_retries);\r\n    printf(\"max retries: %li\\n\", max_retries);\r\n\r\n    return 0;\r\n}\r\n```\r\nOutput:\r\n```\r\nmax retries: 3\r\n```\r\nLite³ provides an alternative API called the 'Context API' where memory management is abstracted away from the user.\r\n\r\nThis example is taken from `examples/context_api/04-nesting.c`. Again, with error handling omitted for brevity:\r\n```C\r\n#include \u003cstdio.h\u003e\r\n#include \u003cstring.h\u003e\r\n\r\n#include \"lite3_context_api.h\"\r\n\r\n\r\nint main() {\r\n        lite3_ctx *ctx = lite3_ctx_create();\r\n        \r\n        // Build message\r\n        lite3_ctx_init_obj(ctx);\r\n        lite3_ctx_set_str(ctx, 0, \"event\", \"http_request\");\r\n        lite3_ctx_set_str(ctx, 0, \"method\", \"POST\");\r\n        lite3_ctx_set_i64(ctx, 0, \"duration_ms\", 47);\r\n\r\n        // Set headers\r\n        size_t headers_ofs;\r\n        lite3_ctx_set_obj(ctx, 0, \"headers\", \u0026headers_ofs);\r\n        lite3_ctx_set_str(ctx, headers_ofs, \"content-type\", \"application/json\");\r\n        lite3_ctx_set_str(ctx, headers_ofs, \"x-request-id\", \"req_9f8e2a\");\r\n        lite3_ctx_set_str(ctx, headers_ofs, \"user-agent\", \"curl/8.1.2\");\r\n\r\n        lite3_ctx_json_print(ctx, 0); // Print Lite³ as JSON\r\n\r\n        // Get user-agent\r\n        lite3_str user_agent;\r\n        size_t ofs;\r\n        lite3_ctx_get_obj(ctx, 0, \"headers\", \u0026ofs);\r\n        lite3_ctx_get_str(ctx, ofs, \"user-agent\", \u0026user_agent);\r\n        printf(\"User agent: %s\\n\", LITE3_STR(ctx-\u003ebuf, user_agent));\r\n\r\n        lite3_ctx_destroy(ctx);\r\n        return 0;\r\n}\r\n```\r\nOutput:\r\n```\r\n{\r\n    \"method\": \"POST\",\r\n    \"event\": \"http_request\",\r\n    \"duration_ms\": 47,\r\n    \"headers\": {\r\n        \"user-agent\": \"curl/8.1.2\",\r\n        \"x-request-id\": \"req_9f8e2a\",\r\n        \"content-type\": \"application/json\"\r\n    }\r\n}\r\nUser agent: curl/8.1.2\r\n```\r\nFor a complete How-to Guide with examples, see [the documentation](https://lite3.io/how_to_guides.html).\r\n\r\n\r\n## Getting Started\r\n### Make Commands\r\n| Command           | Description                                               |\r\n|-------------------|-----------------------------------------------------------|\r\n| `make all`        | Build the static library with -O2 optimizations (default) |\r\n| `make tests`      | Build and run all tests (use VERBOSE=1 for stdout output) |\r\n| `make examples`   | Build all examples                                        |\r\n| `make install`    | Install library in `/usr/local` (for pkg-config)          |\r\n| `make uninstall`  | Uninstall library                                         |\r\n| `make clean`      | Remove all build artifacts                                |\r\n| `make help`       | Show this help message                                    |\r\n\r\n### Installation\r\nA gcc or clang compiler is required due to the use of various builtins.\r\n\r\nFirst clone the repository:\r\n```\r\ngit clone https://github.com/fastserial/lite3.git\r\ncd lite3/\r\n```\r\nThen choose between installation via `pkg-config` or manual linking.\r\n\r\n#### Installation via pkg-config (easiest)\r\nInside the project root, run:\r\n```\r\nsudo make install -j\r\nsudo ldconfig\r\n```\r\nThis will build the static library, then install it to `/usr/local` and refresh the `pkg-config` cache. If installation was successful, you should be able to check the library version like so:\r\n```\r\npkg-config --modversion lite3\r\n```\r\nYou can now compile using these flags:\r\n```\r\n$(pkg-config --libs --cflags --static lite3)\r\n```\r\nFor example, to compile a single file `main.c`:\r\n```\r\ngcc -o main main.c $(pkg-config --libs --cflags --static lite3)\r\n```\r\n#### Installation via manual linking\r\nFirst build the library inside project root:\r\n```\r\nmake -j\r\n```\r\nThen in your main program:\r\n1. Link against `build/liblite3.a`\r\n2. And include: `include/lite3.h` + `include/lite3_context_api.h`\r\n\r\nFor example, to compile a single file `main.c`:\r\n```\r\ngcc -o main main.c -I/path/to/lite3/include /path/to/lite3/build/liblite3.a\r\n```\r\n### Using the library\r\n#### Choose your API\r\nThe Buffer API provides the most control, utilizing caller-supplied buffers to support environments with custom allocation patterns, avoiding the use of `malloc()`.\r\n\r\nThe Context API is a wrapper around the Buffer API where memory allocations are hidden from the user, presenting a more accessible interface. If you are using Lite³ for the first time, it is recommended to start with the Context API.\r\n```C\r\n#include \"lite3.h\"              // Buffer API\r\n#include \"lite3_context_api.h\"  // Context API\r\n```\r\nThere is no need to include both headers, only the API you intend to use.\r\n\r\n#### Library error messages\r\nBy default, library error messages are disabled. However it is recommended to enable them to receive feedback during development. To do this, either:\r\n1. uncomment the line `// #define LITE3_ERROR_MESSAGES` inside the header file: `include/lite3.h`\r\n2. build the library using compilation flag `-DLITE3_ERROR_MESSAGES`\r\n\r\nIf you installed using `pkg-config`, you may need to reinstall the library to apply the changes. To do this, run:\r\n```\r\nsudo make uninstall\r\nsudo make clean\r\nsudo make install\r\nsudo ldconfig\r\n```\r\n#### Building Examples\r\nExamples can be found in separate directories for each API:\r\n- `examples/buffer_api/*`\r\n- `examples/context_api/*`\r\n\r\nTo build the examples, inside the project root run:\r\n```\r\nmake examples -j\r\n```\r\nTo run an example:\r\n```\r\n./build/examples/context_api/01-building-messages\r\n```\r\nFor learning how to use Lite³, it is recommended to follow the [How-to Guide series](https://lite3.io/how_to_guides.html).\r\n\r\n\r\n### Feature Matrix\r\n| Format name                   | Schemaless    | Zero-copy reads[^1]   | Zero-copy writes[^2]  | Human-readable[^3]       |\r\n| ----------------------------- | ------------- | --------------------- | --------------------- | ------------------------ |\r\n| Lite³                         | ✅            | ✅ O(log n)          | ✅ O(log n)           | ⚠️ (convertable to JSON)  |\r\n| JSON                          | ✅            | ❌                   | ❌                    | ✅                        |\r\n| BSON                          | ✅            | ❌                   | ❌                    | ⚠️ (convertable to JSON)  |\r\n| MessagePack                   | ✅            | ❌                   | ❌                    | ⚠️ (convertable to JSON)  |\r\n| CBOR                          | ✅            | ❌                   | ❌                    | ⚠️ (convertable to JSON)  |\r\n| Smile                         | ✅            | ❌                   | ❌                    | ⚠️ (convertable to JSON)  |\r\n| Ion (Amazon)                  | ✅            | ❌                   | ❌                    | ⚠️ (convertable to JSON)  |\r\n| Protobuf (Google)             | ❌            | ❌                   | ❌                    | ❌[^4]                    |\r\n| Apache Arrow                  | ❌            | ✅ O(1)              | ❌ (immutable)        | ❌                        |\r\n| Flatbuffers (Google)          | ❌            | ✅ O(1)              | ❌ (immutable)        | ❌                        |\r\n| Flexbuffers (Google)          | ✅            | ✅[^5]               | ❌ (immutable)        | ⚠️ (convertable to JSON)  |\r\n| Cap'n Proto (Cloudflare)      | ❌            | ✅ O(1)              | ⚠️ (in-place only)    | ❌                        |\r\n| Thrift (Facebook)             | ❌            | ❌                   | ❌                    | ❌                        |\r\n| Avro (Apache)                 | ❌            | ❌                   | ❌                    | ❌                        |\r\n| Bond (Microsoft, discontinued)| ❌            | ⚠️ (limited)         | ❌                    | ❌                        |\r\n| DER (ASN.1)                   | ❌            | ⚠️ (limited)         | ❌                    | ❌                        |\r\n| SBE                           | ❌            | ✅ O(1)              | ⚠️ (in-place only)    | ❌                        |\r\n\r\n[^1]: Zero-copy reads: The ability to perform arbitrary lookups inside the structure without deserializing or parsing it first.\r\n[^2]: Zero-copy writes: The ability to perform arbitrary mutations inside the structure without deserializing or parsing it first.\r\n[^3]: To be considered human-readable, all necessary information must be provided in-band (no outside schema).\r\n[^4]: Protobuf can optionally send messages in 'ProtoJSON' format for debugging, but in production systems they are still sent as binary and not inspectable without schema. Other binary formats also support similar features, however we do not consider these formats 'human-readable' since they rely on out-of-band information.\r\n[^5]: Flexbuffers access to scalars and vectors is `O(1)` (ints, floats, etc.). For maps, access is `O(log n)`.\r\n\r\nRemember that we judge the behavior of formats by their implementation rather than by their official spec. This is because we cannot judge the behavior of hypothetical non-existent implementations.\r\n\r\n\r\n## Benchmarks\r\n### Simdjson Twitter API Data Benchmark\r\nThis benchmark by the authors of [the official simdjson repository](https://github.com/simdjson/simdjson)\r\nwas created to compare JSON parsing performance for different C/C++ libraries.\r\n\r\nAn input dataset `twitter.json` is used, consisting ~632 kB of real twitter API data to perform a number of tasks, each having its own category:\r\n1. **top_tweet**: Find the tweet with the most number of retweets.\r\n2. **partial_tweets**: Iterate over all tweets, extracting only a number of fields and storing it inside an `std::vector`.\r\n3. **find_tweet**: Find a tweet inside the dataset with a specific ID.\r\n4. **distinct_user_id**: Collect all unique user IDs inside the dataset and store it inside an `std::vector\u003cuint64_t\u003e`.\r\n\r\nWhile these tasks are intended to compare JSON parsing performance, they represent real patterns inside applications in which data might be queried.\r\n\r\nText formats do not contain enough information for a parser to know the structure of the document immediately.\r\nThis structure must be 'discovered' by finding brackets, commas, semicolons etc.\r\nThrough this process, the parser acquires information necessary for traversal.\r\nAn unfortunate result of this, is that typically the entire dataset must be fed through the CPU, even if a query is only interested in a subset or single field.\r\n\r\nA zero-copy format will approach each problem in a different way.\r\nIt already contains all the information necessary to find internal fields.\r\nOnly some index structure is required, along with fields of interest. The rest of the dataset is irrelevant to the CPU and might never even enter cache.\r\nTherefore to answer a query like 'find tweet by ID', the actual bytes read may be counted only in the hundreds or low thousands out of ~632 kB.\r\n\r\nConverting the dataset to Lite³ (a zero-copy format) to answer the exact same queries\r\npresents an opportunity to quantify this advantage and reveal something about the cost of text formats.\r\n\r\n![](img/lite3_benchmark_simdjson_twitter_api_data.png)\r\n\r\n| Format               | top_tweet        | partial_tweets   | find_tweet       | distinct_user_id |\r\n| -------------------- | ---------------- | ---------------- | ---------------- | ---------------- |\r\n| yyjson               | 205426 ns        | -                | 203147 ns        | 207233 ns        |\r\n| simdjson On-Demand   | 91184 ns         | 91090 ns         | 53937 ns         | 85036 ns         |\r\n| simdjson DOM         | 147264 ns        | 153397 ns        | 143567 ns        | 150541 ns        |\r\n| RapidJSON            | 1081987 ns       | 1091551 ns       | 1075215 ns       | 1085541 ns       |\r\n| Lite³ Context API    | 2285 ns          | 17820 ns         | 456 ns           | 11869 ns         |\r\n| Lite³ Buffer API     | 2221 ns          | 17659 ns         | 448 ns           | 11699 ns         |\r\n\r\n**To be clear: the other formats are parsing JSON.**  \r\n**Lite³ operates on the same dataset, but converted to binary Lite³ format in order to show the potential.**\r\n\r\nThis benchmark is open source and can be replicated [here](https://github.com/fastserial/simdjson).\r\n\r\n### Kostya JSON Benchmark\r\n[A somewhat popular benchmark](https://github.com/kostya/benchmarks) comparing the performance of different programming languages.\r\nIn the JSON category, a ~115 MB JSON document is generated consisting of many floating point numbers representing coordinates.\r\nThe program will be timed for how long it takes to sum all the numbers.\r\n\r\nThe aim for this test is similar: quantifying the advantage of a zero-copy format.\r\nThis time, reading the entire dataset is unavoidable to produce a correct result.\r\nSo instead, the emphasis will be on text-to-binary conversion.\r\nBecause Lite³ stores numbers natively in 64 bits, there is no need to parse and convert ASCII-decimals.\r\nThis conversion can be tricky for floating point numbers in particular.\r\n\r\n![](img/lite3_benchmark_kostya_json_execution_time.png)\r\n![](img/lite3_benchmark_kostya_json_memory_usage.png)\r\n\r\n| Language / Library            | Execution Time       | Memory Usage         |\r\n| ----------------------------- | -------------------- | -------------------- |\r\n| C++/g++ (DAW JSON Link)       | 0.094 s              | 113 MB               |\r\n| C++/g++ (RapidJSON)           | 0.1866 s             | 238 MB               |\r\n| C++/g++ (gason)               | 0.1462 s             | 209 MB               |\r\n| C++/g++ (simdjson DOM)        | 0.1515 s             | 285 MB               |\r\n| C++/g++ (simdjson On-Demand)  | 0.0759 s             | 173 MB               |\r\n| C/gcc (lite3)                 | 0.027 s              | 203 MB               |\r\n| C/gcc (lite3_context_api)     | 0.027 s              | 203 MB               |\r\n| Go (Sonic)                    | 0.2246 s             | 121 MB               |\r\n| Rust (Serde Custom)           | 0.113 s              | 111 MB               |\r\n| Zig                           | 0.2493 s             | 147 MB               |\r\n\r\n**To be clear: the other formats are parsing JSON.**  \r\n**Lite³ operates on the same dataset, but converted to binary Lite³ format in order to show the potential.**\r\n\r\nThis benchmark is open source and can be replicated [here](https://github.com/fastserial/kostya-benchmark).\r\n\r\n### Cpp Serialization Benchmark\r\nIt is to be expected that binary formats will perform well compared to text formats.\r\nThe comparison however is not entirely unwarranted.\r\nPure binary formats present another category, typically requiring schema files and extra tooling.\r\nThey are chosen by those who value performance over other considerations.\r\nIn doing so, trade-offs are made in usability and flexibility.\r\n\r\nLite³ also being a binary format, rather opts for a schemaless design.\r\nThis produces a more balanced set of trade-offs with the notable feature of JSON-compatibility.\r\n\r\nPerformance of course will remain a strong selling point.\r\nThis next benchmark originates from the [Cista++ serialization library](https://github.com/felixguendling/cpp-serialization-benchmark) to compare several binary formats, including zero-copy formats.\r\nThe measurements cover the time required to serialize, deserialize and traverse a graph consisting of nodes and edges.\r\nThe Cista++ authors created three variants for their format, notably the 'offset' and 'offset slim' variants\r\nwhere the edges use indices to reference nodes instead of pointers.\r\n\r\n![](img/lite3_benchmark_cpp_serialization.png)\r\n\r\n| Name                  | Serialize + Deserialize | Deserialize | Serialize   | Traverse    | Deserialize and traverse | Message size    |\r\n| --------------------- |------------------------ | ----------- | ----------- | ----------- | ------------------------ | --------------- |\r\n| Cap’n Proto           | **66.55 ms**            | 0 ms        | 66.55 ms    | 210.1 ms    | 211 ms                   | 50.5093 MB      |\r\n| cereal                | **229.16 ms**           | 98.76 ms    | 130.4 ms    | 79.17 ms    | 180.7 ms                 | 37.829 MB       |\r\n| Cista++ (offset)      | **913.2 ms**            | 274.1 ms    | 639.1 ms    | 79.59 ms    | 80.02 ms                 | 176.378 MB      |\r\n| Cista++ (offset slim) | **3.96 ms**             | 0.17 ms     | 3.79 ms     | 79.99 ms    | 80.46 ms                 | 25.317 MB       |\r\n| Cista++ (raw)         | **947.4 ms**            | 289.2 ms    | 658.2 ms    | 81.53 ms    | 113.3 ms                 | 176.378 MB      |\r\n| Flatbuffers           | **1887.49 ms**          | 41.69 ms    | 1845.8 ms   | 90.53 ms    | 90.35 ms                 | 62.998 MB       |\r\n| Lite³ Buffer API      | **7.79 ms**             | 4.77 ms     | 3.02 ms     | 79.39 ms    | 84.92 ms                 | 38.069 MB       |\r\n| Lite³ Context API     | **7.8 ms**              | 4.76 ms     | 3.04  ms    | 79.59 ms    | 84.13 ms                 | 38.069 MB       |\r\n| zpp::bits             | **4.66 ms**             | 1.9 ms      | 2.76 ms     | 78.66 ms    | 81.21 ms                 | 37.8066 MB      |\r\n\r\n\r\nThis benchmark is open source and can be replicated [here](https://github.com/fastserial/cpp-serialization-benchmark).\r\n\r\n\r\n## Security\r\nLite³ is designed to handle untrusted messages. Being a pointer chasing format, special attention is paid to security. Some measures include:\r\n- Pointer dereferences preceded by overflow-protected bounds checks.\r\n- Runtime type safety.\r\n- Max recursion limits.\r\n- Generational pointer macro to prevent dangling pointers into Lite³ buffers.\r\n\r\nIf you suspect to have found a security vulnerability, please [contact the developer](mailto:elias@fastserial.com).\r\n\r\n\r\n## Q\u0026A\r\n**Q: Should I use this instead of JSON in my favorite programming language?**  \r\nA: If you care about performance and can directly interface with C code, then go ahead. If not, wait for better language bindings.\r\n\r\n**Q: Should I use this instead of Protocol Buffers (or any other binary format)?**  \r\nA: In terms of encode/decode performance, Lite³ outperforms Protobuf due to the zero-copy advantage. But Lite³ must encode field names to be self-describing, so messages take up more space over the wire. So choose Lite³ if you are CPU-constrained. Are you bandwidth constrained? Then choose Protocol Buffers and be prepared to accept extra tooling, IDL and ABI-breaking evolution to minimize message size.\r\n\r\n**Q: Can I use this in production?**  \r\nA: The format is developed for use in the field, though keep in mind this is a new project and the API is unstable. Also: understand [the limitations](https://lite3.io/design_and_limitations.html). Experiment first and decide if it suits your needs.\r\n\r\n**Q: Can I use this in embedded / ARM?**  \r\nA: Yes, but your platform should support the `int64_t` type, 8-byte doubles and a suitable C11 gcc/clang compiler,\r\nthough downgrading to C99 is possible by removing all static assertions.\r\nThe format has not yet been tested on ARM.\r\n\r\n\r\n## Roadmap\r\n- [ ] Optimize build and add support for `-flto`\r\n- [ ] Built-in defragmentation with GC-index\r\n- [x] Full JSON interoperability with arrays \u0026 nested objects\r\n- [x] Opt-out compilation flag for `yyjson`\r\n- [x] Handling key collisions\r\n- [ ] Size benchmark for compression ratios using different codecs\r\n- [ ] Add language bindings\r\n- [ ] Write formal spec\r\n\r\n\r\n## Mailing List\r\nIf you would like to be part of developer discussions with the project author, consider joining the mailing list:\r\n\r\n`devlist@fastserial.com`        \r\n\r\nTo join, [send a mail](mailto:devlist-subscribe@fastserial.com) to `devlist-subscribe@fastserial.com` with non-empty subject.\r\nYou will receive an email with instructions to confirm your subscription.\r\n\r\nReply is set to the entire list, though with moderation enabled.\r\n\r\nTo quit the mailing list, simply mail `devlist-unsubscribe@fastserial.com`\r\n\r\n\r\n## Credit\r\nThis project was inspired by a paper published in 2024 as *Lite²*:\r\n\u003e Tianyi Chen †, Xiaotong Guan †, Shi Shuai †, Cuiting Huang † and Michal Aibin † (2024).  \r\n\u003e Lite²: A Schemaless Zero-Copy Serialization Format  \r\n\u003e https://doi.org/10.3390/computers13040089\r\n\r\nA serialization format is described where all entries are organized as key-value pairs inside of a B-tree. The paper authors got their idea from SQL databases. They noticed how it is possible to insert arbitrary keys, therefore being schemaless. Also, performing a key lookup can be done without loading the entire DB in memory, thus being zero-copy.\r\n\r\nThey theorized that it would be possible to remove all the overhead associated with a full-fledged database system, such that it would be lightweight enough to be used as a serialization format. They chose the name *Lite²* since their format is lighter than SQLite.  \r\nDespite showing benchmarks, the paper authors did not include code artifacts.\r\n\r\nThe Lite³ project is an independent interpretation and implementation, with no affiliations or connections to the authors of the original Lite² paper.\r\n\r\n\r\n## The Lite³ name\r\nThe name **Lite³** was chosen since it is lighter than Lite².\r\n\u003e TIP: To type `³` on your keyboard on Linux hold `Ctrl`+`Shift`+`U` then type `00B3`. On Windows, use `Alt`+(numpad)`0179`.\r\n\r\n\r\n## License\r\nLite³ is released under the MIT License. Refer to the LICENSE file for details.\r\n\r\nFor JSON conversion, Lite³ also includes `yyjson`, the fastest JSON library in C.\r\n`yyjson` is written by YaoYuan and also released under the MIT License.\r\n\r\n@tableofcontents","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffastserial%2Flite3","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffastserial%2Flite3","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffastserial%2Flite3/lists"}