[C++] Vtable deduplication fails for 64-bit buffers >2GB, causing slow serialization and larger buffers

[gowsiany]

Description

When serializing FlatBuffers with 64-bit offsets (for buffers larger than 2GB), vtable deduplication fails due to incorrect offset calculations. This results in significantly slower serialization times and larger-than-expected buffer sizes due to redundant vtables. Disabling vtable deduplication using fbb.DedupVtables(false) mitigates the issue, which pinpoints the problem to the deduplication logic itself.

Steps to Reproduce

1. Enable 64-bit offsets in FlatBuffers.
2. Serialize a buffer greater than 2GB containing multiple objects with identical layouts.

Observe

• Serialization of large buffers (over 2GB) takes much longer than for smaller buffers.
• The resulting buffer files are noticeably larger than expected when serializing many objects with identical layouts.
• Disabling vtable deduplication with fbb.DedupVtables(false) significantly reduces serialization time, but results in even larger buffer files.

Expected Behavior

• Vtables should deduplicate efficiently, even for 64-bit buffers.
• Serialization time and buffer size should scale reasonably with data size.

Actual Behavior

• Serialization is much slower for large buffers using 64-bit offsets.
• Buffer size increases due to lack of vtable deduplication.
• Disabling vtable deduplication improves speed but increases buffer size further.

Environment

• FlatBuffers version: 25.2.10
• Platform: any platform/compiler with support for 64-bit offsets

Additional Context

The core issue stems from 64-bit offset calculations omitting length_of_64_bit_region_. This exclusion causes vtable candidate addresses to be miscalculated, which prevents deduplication.

A fix that includes length_of_64_bit_region_ in the offset calculation restores correct vtable deduplication and improves serialization performance for large buffers.

[aardappel]

@dbaileychess who wrote this functionality.

[github-actions[bot]]

This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.

[jtdavis777]

not stale - PR opened.