Decode stream try-catch question

[sergeysolovev]

I’ve noticed in this commit adbf30e the code to handle incomplete chunks had been changed to use try-catch. Wondering how it affects performance as using try-catch to control flow usually creates some performance overhead.

I use this package to encode some data I stream over TCP and noticed that ~0.3% of all messages go through try-catch as incomplete (which is of course normal). My boxes are in the same region. Guess this number can be higher than that in some situations (higher load, distance).

[kriszyp]

using try-catch to control flow usually creates some performance overhead.

I think there used to be advise about try/catch statements creating overhead (even with no throws), but AFAIK, and from my tests, that's not really true anymore, try/catch is optimized to the point of no extra overhead.
Throwing and catching errors definitely does have performance overhead though, and can be somewhat expensive. This code was designed with the expectation that the amortized cost of the handling incomplete messages by throwing errors was probably lower than due extra range checks on every single buffer access, regardless of whether or not incomplete messages were even possible. As you pointed out, frequency of going throw the error path of incomplete messages is low, which is part of the calculus of the amortized cost. And furthermore, it seems like it would be unfortunate to penalize users that are using msgpackr for situations where incomplete messages never happen (probably the majority use case), to possibly optimize for infrequent incomplete messages.