...
- Accessors for String and Uuid arrays fields in Xbuf are not currently zero garbage. Consequently, Xbuf may be more expensive than Protobuf for types that use array fields.
XBuf2
| Status | ||||
|---|---|---|---|---|
|
Xbuf is the next version of the Xbuf encoding type. It is 100% wire compatible with Protobuf and Xbuf but offers considerable improvements in performance and memory efficiency over both these encoding types.
| Tip |
|---|
Xbuf2 is the intended future replacement of Xbuf. It is presented in the current version as a separate encoding type only because the API of the generated Xbuf2 classes have some minor compatibilities with the Xbuf generated classes (see below). Therefore, Xbuf2 is being offered as a separate encoding type in the current version. The next major Talon version will only contain the Xbuf encoding type which will be the current Xbuf2 encoding renamed to Xbuf. Talon applications that currently use the Xbuf encoding type, particularly those that use the Xbuf API methods not supported by Xbuf2 are strongly encouraged to move to Xbuf2 to ease the migration to the next major version of Talon. |
Pros:
- All the benefits of Xbuf listed above plus the following
- Fastest serialization of all the encoding types
- Significantly lower memory footprint than the Xbuf
- Lower memory footprint than the Protobuf encoding type
- Between being faster, having a lower memory footprint and being zero garbage, Xbuf2 is a better choice as an encoding type than Protobuf across all dimensions
- Offers several knobs to manage the tradeoff between performance and memory conservation
- Offers multiple data access patterns
- Random access (as is offered by the other encoding types)
- Serial access
- Direct Deserialization: The ability to serially traverse a Google Protobuf encoded buffer and dispatch the fields to the application via a callback
- Direct Serialization: The ability for an application to directly serialize application fields into a buffer in the Google Protobuf wire format
- Optimized for both messages and state
Cons:
- Xbuf2 stores field data off-heap. This can result in more complexities in the following areas
- Troubleshooting issues
- Monitoring memory utilization
- Performing capacity planning particularly related to memory utilization.
Known Limitations:
- Not currently supported for State Replication applications
- Does not support the UUID and Currency field types (including their array variant)
Incompatibilities with Xbuf:
API Differences
For the most part code generated for the different encoding types behaves the same, but there are some key differences that stem from both the underlying serialization mechanisms and features supported.
...