Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

1.8

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"

What did you do?

Run strings/BenchmarkSplit1 benchmark

What did you expect to see?

Same performance as 1.7

What did you see instead?

3x slowdown
Split1-4 12.0ms ± 0% 52.7ms ± 2% +337.56% (p=0.002 n=6+6)

I've also reproduced this on tip. 8946502 renamed Split1 to SplitEmptySeparator, but kept benchmark the same.
This performance regression was caused by b92d39e
Investigation shows that extra time is spent in mostly GC,runtime.procyield and runtime.writebarrierptr_prewrite1. This is due to missing stack check prologue in utf8.DecodeRuneInString (disabling this optimization for DecodeRuneInString removes regression), which is called in a loop inside a benchmark.
Because of missing stack size check goroutine cannot be preempted, preventing concurent GC and resulting in worse performance.
If #10958 is fixed, this particular regression should disappear.
I'm not sure whether having more preemption points is more important than having lower call overhead.