aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/src/base/diameter_codec.erl
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2017-08-08 16:20:00 +0200
committerAnders Svensson <[email protected]>2017-08-10 11:16:00 +0200
commitd1f4369afb9fb9453ebe8868d88ae299d908a2e4 (patch)
tree1a56476d3a70e00e85447854bdd508b70bfa3b1b /lib/diameter/src/base/diameter_codec.erl
parentca68fe8c449a170f64fd9b41b710ac67966be2ee (diff)
downloadotp-d1f4369afb9fb9453ebe8868d88ae299d908a2e4.tar.gz
otp-d1f4369afb9fb9453ebe8868d88ae299d908a2e4.tar.bz2
otp-d1f4369afb9fb9453ebe8868d88ae299d908a2e4.zip
Avoid unnecessary copying of binaries in diameter_tcp
Since messages are accumulated by appending binaries as of three commits back, the accumulated binary is prone to being copied, as discussed in the Efficiency Guide. Matching the Message Length header as bytes are being accumulated is one cause of this, so work around it by splitting the binary and extracting the length without a match. This doesn't feel like something that should be necessary: that matching a binary would cause an append to copy isn't obvious. The first attempt at simplifying the accumulation was simply to append an incoming binary to the current fragment, match against <<_, Len:24, _/binary>> to extract the length, and then test if there are enough bytes for a message. This lead to horrible performance (response times for 2 MB messages approximately 100 times worse than previously), and it wasn't at all obvious that the reason was the accumulated binary being copied with each append as a result of the match. Using split_binary avoids the match context that forces the copying.
Diffstat (limited to 'lib/diameter/src/base/diameter_codec.erl')
0 files changed, 0 insertions, 0 deletions