use fory::{Fory, ForyObject};

    #[derive(ForyObject, Debug, PartialEq)]
    struct Struct {
        nan: f32,
        inf: f32,
    }

    fn main() {
        let mut fory = Fory::default();
        fory.register::<Struct>(1).unwrap();

        let original = Struct {
            nan: f32::NAN,
            inf: f32::INFINITY,
        };
        dbg!(&original);

        let serialized = fory.serialize(&original).unwrap();

        let back: Struct = fory.deserialize(&serialized).unwrap();
        dbg!(&back);
    }

     cargo run
       Compiling rust-seed v0.0.0-development (/home/random-code/fory-nan-inf)
        Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.28s
         Running `target/debug/fory-nan-inf`
    [src/main.rs:17:9] &original = Struct {
        nan: NaN,
        inf: inf,
    }
    [src/main.rs:22:9] &back = Struct {
        nan: NaN,
        inf: inf,
    }

https://fory.apache.org/docs/docs/introduction/benchmark

https://fory.apache.org/docs/docs/guide/rust_serialization

[0] https://fory.apache.org/blog/2025/10/29/fory_rust_versatile_...

Otherwise, the schema seems to be derived from the class being serialized for typed languages, or otherwise annotated in code. The serializer and deserializer code must be manually written to be compatible instead of both sides being codegen'd to match from a schema file. He's the example I found for python: https://fory.apache.org/docs/docs/guide/python_serialization...

https://github.com/apache/fory/tree/main/python#serialize-lo...

When serializing code objects, pyfory is 3× higher compression ratio compared cloudpickle

And pyfory also provide extra security audit capability to avoid maliciously deserialization data attack.

The way I think about it is: • Single‑language projects often work best without an IDL — it keeps things simple and avoids extra steps. • Two languages – both IDL and no‑IDL approaches can work, depending on the team’s habits. • Three or more – an IDL can be really useful as a single source of truth and to avoid manually writing struct definitions in every language.

For Apache Fory, my plan is to add optional IDL support, so teams who want that “single truth” can generate definitions automatically, and others can continue with language‑first development. My hope is to give people flexibility to choose what fits their situation best.

https://fory.apache.org/blog/fury_blazing_fast_multiple_lang...

But flatbuffers is _much_ faster than protobuf/json:

https://flatbuffers.dev/benchmarks/

Apache Fory, on the other hand, has its own wire‑stream format designed for sending data across processes or networks. Most of the code is focused on efficiently converting in‑memory objects into that stream format (and back) — with features like cross‑language support, circular reference handling, and schema evolution.

Fory also has a row format, which is a memory format, and can complement or compete with Arrow’s columnar format depending on the use case.

| data type | data size | fory | protobuf |

| --------------- | --------- | ------- | -------- |

| simple-struct | small | 21 | 19 |

| simple-struct | medium | 70 | 66 |

| simple-struct | large | 220 | 216 |

| simple-list | small | 36 | 16 |

| simple-list | medium | 802 | 543 |

| simple-list | large | 14512 | 12876 |

| simple-map | small | 33 | 36 |

| simple-map | medium | 795 | 1182 |

| simple-map | large | 17893 | 21746 |

| person | small | 122 | 118 |

| person | medium | 873 | 948 |

| person | large | 7531 | 7865 |

| company | small | 191 | 182 |

| company | medium | 9118 | 9950 |

| company | large | 748105 | 782485 |

| e-commerce-data | small | 750 | 737 |

| e-commerce-data | medium | 53275 | 58025 |

| e-commerce-data | large | 1079358 | 1166878 |

| system-data | small | 311 | 315 |

| system-data | medium | 24301 | 26161 |

| system-data | large | 450031 | 479988 |

Fory’s format was designed from the ground up to handle those cases efficiently, while still enabling cross‑language compatibility and schema evolution.

I can see the source of an 10x improvement on an Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz, but it drops to 3x improvement when I remove the to/from that clones or collects Vecs, and always allocate an 8K Vec instead of a ::Default for the writable buffer.

If anything, the benches should be updated in a tower service / codec generics style where other formats like protobuf do not use any Fory-related code at all.

Note also that Fory has some writer pool that is utilized during the tests:

https://github.com/apache/fory/blob/fd1d53bd0fbbc5e0ce6d53ef...

Original bench selection for Fory:

    Benchmarking ecommerce_data/fory_serialize/medium: Collecting 100 samples in estimated 5.0494 s (197k it
    ecommerce_data/fory_serialize/medium
                            time:   [25.373 µs 25.605 µs 25.916 µs]
                            change: [-2.0973% -0.9263% +0.2852%] (p = 0.15 > 0.05)
                            No change in performance detected.
    Found 4 outliers among 100 measurements (4.00%)
      2 (2.00%) high mild
      2 (2.00%) high severe

    Benchmarking ecommerce_data/protobuf_serialize/medium: Collecting 100 samples in estimated 5.0419 s (20k
    ecommerce_data/protobuf_serialize/medium
                            time:   [248.85 µs 251.04 µs 253.86 µs]
    Found 18 outliers among 100 measurements (18.00%)
      8 (8.00%) high mild
      10 (10.00%) high severe

    fair_ecommerce_data/protobuf_serialize/medium
                            time:   [73.114 µs 73.885 µs 74.911 µs]
                            change: [-1.8410% -0.6702% +0.5190%] (p = 0.30 > 0.05)
                            No change in performance detected.
    Found 14 outliers among 100 measurements (14.00%)
      2 (2.00%) high mild
      12 (12.00%) high severe

I’m curious though: what’s an example scenario you’ve seen that requires so many distinct types? I haven’t personally come across a case with 4,096+ protocol messages defined.