Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
encoding/hex: change lookup table from string to array
name old time/op new time/op delta Encode/256-4 431ns ± 2% 391ns ± 2% -9.36% (p=0.000 n=8+8) Encode/1024-4 1.68µs ± 0% 1.51µs ± 0% -9.91% (p=0.001 n=7+7) Encode/4096-4 6.68µs ± 0% 6.03µs ± 1% -9.69% (p=0.000 n=8+8) Encode/16384-4 27.0µs ± 1% 24.0µs ± 0% -11.03% (p=0.000 n=8+7) Change-Id: I6994e02f77797349c4e188377d84f97dffe98399 Reviewed-on: https://go-review.googlesource.com/27254 Reviewed-by: Brad Fitzpatrick <[email protected]> Run-TryBot: Brad Fitzpatrick <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
- Loading branch information
57370a8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering why is there 10% difference in this case, so for anyone interested, here are the relevant assembler outputs generated for Encode function with go1.7, after ssa, from the GOSSAFUNC= output:
With string:
With []byte:
The only difference I can see is the variant with string loads the pointer to string twice every iteration of Encode, whereas the []byte variant loads it only once, at the top of the function (but I'm not very good at reading assembly, feel free to correct me). Shouldn't this be optimized the same way, since both the string and []byte variant are constants?
57370a8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tasssadar, nobody on the Go team uses Github for comments on code (since we use Gerrit for code review). We only use Github for the bug tracker.
Please file a compiler optimization bug. Maybe you can include a minimal repro demo too with Benchmark functions.