@luxinxin 我做了十万次然后对比的时间。。。

@luxinxin 你之前有类似的测试吗？

我只统计了 tensorflow 的 predict 函数调用时间，tensorflow 启动和数据准备时间都被排除了。除非在 predict 函数内部的启动，这个也无法排除。

batch size 一样。模型也一样。数据也一样。

@rexcelia 你能联系上他们吗？

@wutiantong 哈哈，可是这烂摊子都是我写的啊。

感觉项目一大，各种坑会不断冒出来。见得多就好了。

虽然还没搞清楚确切的原因，但很可能跟分配了大量细碎的内存片段有关。我打算把 circular_buffer 都用内存池管理起来。

查看了 boost::circular_buffer 的源代码，它用的 allocator 就是 std::vector::allocator，但跟 std::vector 不一样在于，circular_buffer 不会对内存初始化。

内存没用不占用可能是操作系统搞的，虽然分配了地址，但不用就不分配实际物理地址，导致不会实际占用物理内存。

delete 不回收内存的原因还是没搞清楚。

再补充一下我试验的结果：

我确定 boost::circular_buffer 这个东西的内存实现和常规的不太一样，具体表现在分配的空间如果没有实际用上，那么并不会占用太多的内存。有点类似于按需扩容，但我看 boost 的文档，这东西应该是在初始化一次性分配内存的。

The circular_buffer only allocates memory when created, when the capacity is adjusted explicitly, or as necessary to accommodate resizing or assign operations.

但我也没试验出 delete 之后的内存不释放的情况。可能跟上面发现的特性有关。

@codehz ABI 兼容性应该没问题。那个 so 也是我自己编译的，同一系统同样环境。

再说能提示下，怎么检查 ABI 兼容性问题吗？

@wwqgtxx 能简化复现的 bug，不会贴到这里麻烦网友们。

@GeruzoniAnsasu 我多挂载的 so 也是我写的，里面很简单。唯一有问题的，可能在这个 so 也链接 boost circular_buffer 以及我那个类 T 的实现。

现在看来可能是 circular_buffer 的 allocate/deallocate 可能有问题。

@wutiantong 在扇贝 C++写得多不？

我上面写的有一定简化。

原始对象其实是一个 T，里面有两个成员都是 vector of cirular_buffer of int。

我 new 和 delete 的都是 T。

@willm 重载是不可能的，我没写过这么底层的东西，要么就是 boost 里面的实现有重载。

我怀疑跟 runtime link 有关系。

我就喜欢在 C++里用 printf。std::cout 又丑又难用。

std::cout 号称更安全一点，但只要自己注意点，printf 也没啥，再说现在编译器也能识别出大部分不安全的情况。

@lcdtyph so 文件是 dlopen 打开的，不是编译时链接。链接时只链接了.a 文件。

现在看 dlopen 的 runtime link 有些难以琢磨的东西。

@lcdtyph 你是最接近答案的人 :)

@lcdtyph 我已经解决了，把那些 static 成员标记为 hidden 即可。

@lcdtyph 这不行的。不链编译通不过。

找到一模一样的问题： https://stackoverflow.com/questions/2631918/main-program-and-shared-library-initializes-same-static-variable-in-static-ini

@hitmanx 我没加这个。不过我试了下加这个编译参数，还是会运行出错。

我用 nm 命令检查了符号，发现原始没出问题的代码，exe 程序里没有`Token`类的实现，所有 so 文件在运行时都使用各自文件里的实现。

但出问题的代码里，exe 程序里有 Token 类的实现，so 文件在运行时直接用了主程序里的实现。

其中 so 文件我没有重新编译过，所以出问题是发现在运行而不是编译时的函数链接上。