Skip to content

Do not encode message to check its validity after decoding#353

Closed
marselester wants to merge 1 commit intogodbus:masterfrom
marselester:noenc-in-dec
Closed

Do not encode message to check its validity after decoding#353
marselester wants to merge 1 commit intogodbus:masterfrom
marselester:noenc-in-dec

Conversation

@marselester
Copy link
Contributor

Hi! I am not 100% sure, but encoding a message with msg.EncodeTo to check whether the message is valid right after it was decoded looks redundant and it incurs 2.9kB and 140 allocs per operation. If the message was corrupted, it would have failed earlier at the decoding stage in unixTransport.ReadMessage.

$ go test -run='^$' -benchmem -bench '^BenchmarkUnixFDs$'
# new
BenchmarkUnixFDs-2   	    8366	    279509 ns/op	   13437 B/op	     465 allocs/op
# old
BenchmarkUnixFDs-2   	    7744	    329736 ns/op	   16275 B/op	     605 allocs/op

$ benchstat bench-old.txt bench-noenc.txt
name       old time/op    new time/op    delta
UnixFDs-2     311µs ±49%     250µs ±30%     ~     (p=0.105 n=10+10)

name       old alloc/op   new alloc/op   delta
UnixFDs-2    16.3kB ± 0%    13.4kB ± 0%  -17.44%  (p=0.000 n=9+9)

name       old allocs/op  new allocs/op  delta
UnixFDs-2       605 ± 0%       465 ± 0%  -23.14%  (p=0.000 n=10+10)

Encoding a message with msg.EncodeTo to check
whether the message is valid right after it was decoded
looks redundant and incurs 13.4kB, 140 allocs per operation.
If the message was corrupted,
it would have failed at the decoding stage in ReadMessage.
@marselester marselester changed the title Do not check message validity after decoding Do not encode message to check its validity after decoding Feb 9, 2023
Copy link
Member

@guelfey guelfey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, just encoding everything again is definitely not needed. But skipping this would also skip the header verification which we definitely should keep

@guelfey
Copy link
Member

guelfey commented Apr 9, 2023

Included in #364. Thanks!

@guelfey guelfey closed this Apr 9, 2023
@marselester
Copy link
Contributor Author

Awesome 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants