append()的 平均（摊销）成本已经是O（1），因为它每次都会使数组增加一个百分比。随着阵列变大，增长变得越来越昂贵，但比例却越来越少。10M项切片的增长成本比1M项切片的成本高10倍，但是由于我们分配的额外容量与大小成正比，因此
append(slice,item)在下一次增长之前，其调用数也将是其10倍。重新分配的增加的成本和减少的频率会抵消，从而使平均成本保持不变，即O（1）。
同样的想法也适用于其他语言的动态大小的数组：例如，Microsoft的
std::vector实现显然每次将数组增长50％。摊销O（1）并不意味着您无需为分配支付任何费用，只是意味着您继续以与数组变大相同的平均费率支付费用。
在我的笔记本电脑上，我可以
slice = append(slice,someStaticString)在77毫秒内运行一百万秒。siritinga在下面指出，它之所以很快是一个原因，就是“复制”字符串以扩大数组实际上只是复制字符串标题（指针/长度对），而不是复制内容。100,000个字符串标题仍不足2MB进行复制，与您要处理的其他数据量相比，这并不算什么。
container/list
在微基准测试中，我的速度降低了约3倍；当然，链表附加也是固定时间，但是我想append
它的常数较低，因为它通常只能写到几个内存中，而不分配列表项，等等。计时码在Playground中不起作用但您可以在本地复制并运行它以查看自己的身份：http- //play.golang.org/p/uYyMScmOjX
但是您在这里询问有关类似
grep应用程序的更具体问题（并感谢您提出有关上下文的详细问题）。为此，最重要的建议是，如果您要搜索大量的日志，则最好避免完全在RAM中缓冲整个输出。
你可以写的东西流的结果作为一个单一的功能：
logparser.Grep(in io.Reader, out io.Writer, patterns[]regexp.Regexp); 你可以或者让
out一个
chan []byte或者
func(match []byte) (errerror)，如果你不希望将结果发送到与grep的代码过于沉浸代码。
（在
[]bytevs上
string：在您执行I / O时，a
[]byte似乎可以完成此工作，并且避免了
[]byte<=>
string转换，所以我更愿意这样做。但是，我不知道您在做什么，以及是否需要
string没关系。）
如果 确实_将整个匹配列表保留在RAM中，请注意，保留对大字符串或字节片的一部分的引用可以防止整个源字符串/片被垃圾回收。因此，如果走那条路线，那么反直觉地，您实际上可能
_想要 复制匹配项，以避免将所有源日志数据保留在RAM中。
