在Go生态已经有很多WEB框架，但感觉没有一个符合我们的想法，我们想要一个简洁高效的核心框架，提供路由，context，中间件和依赖注入，而且拒绝使用正则和反射，于是我们开始构建Baa框架。一开始使用最简单的通俗写法实现了第一版的功能，基本可用，但是性能烂到爆，优化之路漫漫开启。

最好的文章应该是每一步都加上优化前后的benchmark对比结果，给读者以最直观的感受。我先BS一下自己，因为我懒了，没有再回头一步步去对比这个结果图。

拒绝正则和反射

这是我们做这个框架时的一个基本原则，整个实现中没有使用过regexp、reflect包。这是我们对性能追求的基础。带来的另一个收益是，没有魔法，都是非常容易理解的实现，让整个框架变得简单。

使用sync.Pool重用对象

在我上次翻译的文章CockroachDB GC优化总结中介绍过这些方法，在《Go语言圣经》中作者也介绍了这个方法，使用 sync.Pool 可以在一次GC之间重用对象，避免对象的频繁创建和内存分配。我们在追求性能的过程中，要尽可能减少甚至达到内存零分配，这是一个最重要的用法。

在Baa中有如下代码片段：

b.pool = sync.Pool{
    New: func() interface{} {
        return newContext(nil, nil, b)
    },
}

使用的时候：

c := b.pool.Get().(*Context)
c.reset(w, r)

使用完：

b.pool.Put(c)

使用array优化slice

slice的本质就是就是一个可变长度的array，根据存储的容量会动态的重新分配内存迁移数据。如果长度不断变化，会导致不断的重新分配内存，在特定场景下，如果我们可以使用一个定长的array来优化内存分配。

VAR nameArr [1024]string
pnames := nameArr[0:0]
pNames = apPEnd(pNames, "val")

pNames 是一个slice，但数据操作总是在array nameArr上完成，在整个使用过程中不会重新分配内存。

上面的伪代码，在Baa中已经不存在了，Baa改用了下面的技巧来取代定长的array。

slice也能重用

slice的重用，其实和上面的利用array优化基本一致，就是初始分配一个较大的容量，尽可能在使用的过程中都不会超出容量，当然也不用担心，万一不够用了，会自动扩容，只不过会进行一次内存分配。

在Baa中有如下代码片段：

// newContext create a http context
func newContext(w http.ResponseWrITer, r *http.Request, b *Baa) *Context {
    c := new(Context)
    c.Resp = NewResponse(w, b)
    c.baa = b
    c.pNames = make([]string, 0, 32)
    c.pvalues = make([]string, 0, 32)
    c.handlers = make([]HandlerFunc, len(b.middleware), len(b.middleware)+3)
    copy(c.handlers, b.middleware)
    c.reset(w, r)
    return c
}

// reset ...
func (c *Context) reset(w http.ResponseWriter, r *http.Request) {
    c.Resp.reset(w)
    c.Req = r
    c.hi = 0
    c.handlers = c.handlers[:len(c.baa.middleware)]
    c.pNames = c.pNames[:0]
    c.pValues = c.pValues[:0]
    c.Store = nil
}

注意newContext中的 c.pNames和c.pValues 以及 reset中的 c.pNames和c.pValues，通过 slice[:0] 来重用之前的slice，避免内存重新分配。至于上面的长度32，是根据经验得来的一个值，尽可能保证长度满足大部分情况下的需求又不太大。

使用Radix tree重写路由

之前在黑夜路人微信群中还讨论过一个问题：算法、数据结构，在实际工作中有用到过吗？说实话，一般情况下真不怎么用到，不过这里就是一个场景。

在第一版中，路由就是一个map，路由匹配就是一个range，简单，清晰，但性能自然不好。参考了 macaron和echo框架的设计，都是使用基数树(radix tree)来实现的，只是实现的细节不同，这里我们也有不同的细节实现，但思路基本没变。具体实现可以参考 wiki，和 Baa router部分 router.go

string的性能不怎样

很多文章介绍过了，尽量使用 []byte 替代 string，这里我们也是这么做的。

Map的range好低效

map和slice的range性能差一个数量级啊，所以，你会发现我们取消了大量的map改为了slice，在slice也能重用这一节的代码示例中 pNames和pValues就是用来取代原来的 map[string]string，因为map range的效率太低了。

凡是迭代就有开销

slice的迭代是很快，可是总还是迭代，是迭代就有开销，为了追求极致的性能也是疯了。在路由匹配时，我们给所有的路由pattern设置了单字节的index，如果首字母都不匹配，就没有必要继续后面的字符匹配了。

路由条目创建：

// newRoute create a route item
func newRoute(pattern string, handles []HandlerFunc, router *Router) *Route {
    r := new(Route)
    r.pattern = pattern
    r.alpha = pattern[0]
    r.handlers = handles
    r.router = router
    r.children = make([]*Route, 0)
    return r
}

路由条目匹配：

// findChild find child static route
func (r *Route) findChild(b byte) *Route {
    var i int
    var l = len(r.children)
    for ; i < l; i++ {
        if r.children[i].alpha == b && !r.children[i].hasParam {
            return r.children[i]
        }
    }
    return nil
}

注意 r.alpha 就是用来尽可能避免迭代进一步提高性能的。

defer也仅是方便

在追求极致性能的路上，我都快疯了，在一步步测试的过程中，发现去掉defer也能提高一些性能，雨痕学堂微信公众号 中的一篇文章也提到了这个问题，因为defer有额外的开销来保证延迟调用甚至panic时也能执行，而大多数时候我们可以在程序的结束时直接终止，避免defer机制，再快一点点。

函数调用也是开销

离目标越来越近，但还有一点差距，我们也越来越疯狂，最后居然干成了这样，我们把部分频繁调用的函数取消，改为直接在一个函数中完成，因为我们发现，即使只是一个函数调用，TMD也是开销呀。

pPRof是神器

在整个过程中，如何一步步分析性能问题，定位可优化的地方，go test -cpuprofile, go test -memprofile, go test -bench 就是最好的工具，每修改一次，bench看结果，profile看性能分析。

总结

本文简单总结了在优化过程中的各种技巧，和部分代码示例，更多使用姿势，自行体验，欢迎交流和拍砖。