Use cheaper operation to estimate json data byte size

[tuliren]

What

• Currently we calculate the JSON byte size by converting the serialized JSON string to a byte array, and use the length of the byte array.
• This operation happens for every JSON data in the Airbyte message. This is known to be expensive in memory consumption.
  • Observation: [EPIC] scale warehouse destination connectors to handle arbitrary number of streams #10260 (comment)
  • It's expensive probably because of the multiple array copy operations in the String#getBytes method.

How

• Replace the current byte size calculation with simply the length of the serialized JSON string.
• The rationale is that the most frequent characters are in ASCII, and they all take only one byte in UTF-8 encoding.

[evantahler]

Comment below, but it's an optimization. This is better than what we have now, so perhaps this is merged as-is, and we can look at an even more memory-safe later.

[evantahler]

Since we are already playing the game of memory optimization, and we are comfortable with estimates, is there a way we can get the size of the object without re-serializing the instance back to a string again? That's also got overhead...

A rough approximation could be to store a constant for how much memory an empty JsonNode takes in bytes, and subtract that from this instance's size maybe?

Alternatively, before we parse the message, could we get the string length then and store that value as a property of AirbyteMessage... perhaps AirbyteMessage.originalMessageSize

[tuliren]

A rough approximation could be to store a constant for how much memory an empty JsonNode takes in bytes, and subtract that from this instance's size maybe?

By "this instance's size", do you mean the serialized byte size or the size in memory of a JsonNode instance? There is no good way to measure an object's size in memory though. The libraries that can do this usually have large overhead, and are not recommended for production.

It's possible to implement one by tracking the JSON field and value sizes in the JsonNode object itself. However, that requires forking the jackson library and more complicated work.

Alternatively, before we parse the message, could we get the string length then and store that value as a property of AirbyteMessage... perhaps AirbyteMessage.originalMessageSize

That's a good idea. Somewhere in the source, it's probably serializing the data inside message already. So we can store the serialized string size as a field in AirbyteMessage. However, I cannot find where we construct the AirbyteMessage in the upstream.

I will merge this PR as is for now.

[cgardens]

looks good.

earlier in the stack, we have the serialized version of the message. we deserialize it and then the serialized version gets garbage collected. if we ever do need the exact counts, we can just keep the serialized version in memory and pass it through the stream and count it directly.

that said, i think your approach makes the right tradeoffs for us now.

[tuliren]

earlier in the stack, we have the serialized version of the message

Do you know where it is? I'd like to take a look and see if we can cache the size in AirbyteMessage in a field there (as suggested by Evan) to completely avoid doing the serialization in the message tracker.

[cgardens]

yeah! DefaultAirbyteStreamFactory is the class that listens on STDIN for anything emitted from the source.