is called so often that performance is hindered by the fact that it does
not inline. About 1/3rd of the time is spent on this function.
. . 59:// Peek returns the ith byte relative to the
end position and possibly does an allocation. Calling Peek may invalidate
previous returned byte slices by Bytes or Shift, unless IsEOF returns true.
. . 60:// Peek returns zero when an error has
occurred, Err return the error.
208ms 208ms 61:func (z *Shifter) Peek(i int) byte {
15ms 15ms 62: end := z.end + i
15ms 15ms 63: if end >= len(z.buf) {
1ms 1ms 64: if z.err != nil {
1ms 1ms 65: return 0
. . 66: }
. . 67:
. . 68: // reallocate a new buffer
(possibly larger)
. . 69: c := cap(z.buf)
. . 70: d := len(z.buf) - z.pos
. . 71: var buf []byte
. . 72: if 2*d > c {
. . 73: buf = make([]byte, d, 2*c+
end-z.pos)
. . 74: } else {
. . 75: buf = z.buf[:d]
. . 76: }
. . 77: copy(buf, z.buf[z.pos:])
. . 78:
. . 79: // read in to fill the buffer till
capacity
. . 80: var n int
. . 81: n, z.err = z.r.Read(buf[d:cap(buf)])
. . 82: z.eof = (z.err == io.EOF)
. . 83: end -= z.pos
. . 84: z.end -= z.pos
. . 85: z.pos, z.buf = 0, buf[:d+n]
. . 86: if n == 0 {
. . 87: return 0
. . 88: }
. . 89: }
70ms 70ms 90: return z.buf[end]
. . 91:}
This function is pretty small, except when `end >= len(z.buf)` is true. So
if the contents of the if-statement was a function, the Peek function could
benefit from being inlined.
What are my options here? Can I redesign this to encourage inlining?
Thoughts?
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.