Zero-alloc #[serde(flatten)] deserialization appears to be possible - should we finish the work?

[Ten0]

Specifically, it appears to be possible to alter the Deserialize derive in a fully backwards-compatible manner with regards to the current behavior of #[serde(flatten)] and leaving the existing trait system untouched, such that deserializing a struct that contains a single flattened field does not allocate a temporary storage for all fields that are unknown from the outer struct.

This seems to have a typical performance impact of ~50% cut on deserialization.

regular/vanilla         time:   [203.83 ns 204.42 ns 205.23 ns]
regular/zero_alloc      time:   [103.64 ns 103.97 ns 104.38 ns]

This has an even more significant performance impact (for my simple benchmark I get an 86% cut) for use-cases where the program deserializing cares only about a subset of all the fields, as these are completely skipped with this approach, whereas they would be allocated and re-processed with the current approach.

worse_case/vanilla      time:   [1.0458 ms 1.0469 ms 1.0481 ms]
worse_case/zero_alloc   time:   [141.04 µs 141.39 µs 141.69 µs]

This only works for structs that contain one flattened field (structs that have multiple #[serde(flatten)] fields would have to fallback to the current implementation).

How it works

The general idea is that we can pass a wrapped Deserializer to the flattened struct, which will pass a wrapped MapAccess to its visitor, which will only yield keys that don't match the outer struct. If they do match, the serializer will fill these fields in the outer struct instead.

Because the original MapAccess has to be driven by the flattened field (because Visitors drive the MapAcceses), it appears to not be possible to make this approach work when there are multiple flattened fields.

Pros and cons

Pros

• Very significant perf. increase on single #[serde(flatten)] uses. (On our pretty large Rust codebase, we have 108 #[serde(flatten)], and 100% of the deserializations among those only contain a single flattened field, so that seems to represent the large majority of use-cases.)
• #[serde(flatten)] typically now works in no-std environments
• Fully backwards-compatible - no update to the existing trait system and no additional public interface.
• Alternately to full-backwards-compatibility, this may help with issues such as #1183 by getting rid of internal buffering for this case

Cons

• This introduces significant additional complexity to the flatten feature. Notably the code generated by #[derive(Deserialize)] is significantly different because the MapAccess has to be driven by the flattened field. Basically no complexity is removed, because support for multiple flattened fields would still depend on the current implementation.

Should we finish the work?

This is clearly only at the POC state currently - notably enums are unsupported and some edge-cases may not be properly considered yet.

I'd like to know whether this looks like something that likely could be integrated into serde before I dedicate more time into making this closer to a PR-able state.

[Elrendio]

Hello @dtolnay,

If you validate that you would be open to such a change we would gladly provide the further analysis and the PR.

Thanks a have a nice day!

[oli-obk]

The main issue I see is with review capacity. There are already lots of open PRs, so even if the change is desirable and made, the PR will go unreviewed for many months.

[Elrendio]

Hello @oli-obk,

Thanks for the feedback!

Is there any thing we can do to shorten the review time, I have in mind:

• Extensive testing
• Performance testing
• High level architecture explanation
• In depth documentation

Something else?

Thanks 🙏

[oli-obk]

That's unfortunately not the issue. The PRs we get are almost exclusively well documented and tested. We have 46 PRs open, and manage to merge around 1-2 PRs per month, while around 2-10 PRs are opened per month, so we just can't keep up at all.