前言
上一期我们对整个项目进行了细节部分的优化，并在最后测试了多线程环境下和malloc的性能对比测试，发现malloc有时候还是更胜一筹的，基于此我们进行对我们的内存池进行瓶颈分析与优化。
一、项目瓶颈分析
经过前面的测试可以看到，我们的代码此时与malloc之间还是有差距的，此时我们就应该分析分析我们当前项目的瓶颈在哪里，但这不能简单的凭感觉，我们应该用性能分析的工具来进行分析。
VS编译器下性能分析的操作步骤
VS编译器中就带有性能分析的工具的，我们可以依次点击。"调试-》性能探测器"进行分析。注意：该过程一定是在Debug模式下的。
同时我们将代码中n的值由10000调成了1000，否则该分析过程可能会花费较多时间，并且将malloc的测试代码进行了屏蔽，因为我们要分析的是我们实现的高并发内存池。
cpp
int main()
{
size_t n = 1000;
cout << "==========================================================" <<
endl;
BenchmarkConcurrentMalloc(n, 4, 10);
cout << endl << endl;
//BenchmarkMalloc(n, 4, 10);
cout << "==========================================================" <<
endl;
return 0;
}勾选 检测-》开始
然后会弹出一个框，我们选择我们要分析的项目，确定即可
分析性能瓶颈
通过分析结果可以看到，光是Deallocate和MapObjectToSpan这两个函数就占用了一半多的时间。 而MapObjectToSpan是占用消耗时间最多的。
我们点击去看看MapObjectToSpan，发现是因为加锁的就消耗了47%的时间
在来点到Deallocate看看，发现是ListTooLong占用的多
继续点到ListTooLong看看，发现是RleaseListToSpan
继续点到RleaseListToSpan看看，发现是MapObjectToSpan
这里我们再点击去就肯定是锁的问题了：
因此当前项目的瓶颈点就在锁 竞争上面，需要解决调用MapObjectToSpan函数访问映射关系时的加锁问题。tcmalloc当中针对这一点使用了基数树进行优化，使得在读取这个映射关系时可以做到不加锁。