Performance

[bsideup]

The problem

The current balance is leaning towards the usability of the SDK vs performance. Hot spots:

• Optional usage - mandatory allocations
• Streams where unnecessary - after I rewrote this code with plain old for-in, it was allocating much less and even easier to understand
• Remove Attributes interface #118
• always deserialized extensions - not possible to "read CloudEvent -> change type -> write CloudEvent" without having to decode the extensions

While it creates a good first experience, not being able to exchange typed CloudEvents in the app can be critical for performance concerned systems and may lead to a fragmentation, because every such project will implement its own CloudEvent type that is binary incompatible to the "official" one (from the reference SDK).

The suggestion

Consider having low-level and (mid|high)-level APIs, so that the official SDK can still be used to represent a common type without paying the performance cost.

Ideally, the low level object should be exactly one allocation, close to the wire and provide efficient ways of decoding/encoding (e.g. ByteBuffers).

The (mid|high)-level API would allow deserialization of the extensions and data. The low level object can be used as an underlying representation.

[slinkydeveloper]

I mark this one as invalid, since the 4 points you described are already discussed in other issues and the others doesn't apply any more to master. We now have a low level api (Message) and an high level one (Event).