接口做完了，当然要好好测一下了，何况原来就发现过内存泄露的问题。

原来的问题是绘出的帧数，随着运行时间的增加会慢慢减少，这在dof节点上表现尤为明显。考虑到有内存泄露，我们决定采用boundchecker来进行测试。

刚开始装的时候我们还小心翼翼的，怕这种可以调试系统的会一不小心破坏掉系统，那可就赔了夫人又折兵了。但是yyd装了之后发现一切正常，于是才敢装起来。

下面就是尝试使用了，不管三七二十一，先跑上一段程序看看。开了boundschecker开始debug，立刻发现boundschecker开始报错，我的天，好多，上万条。怎么回事呢？难道我们的程序那么烂吗？仔细研究一下发现，原来boundschecker也是需要好好配置一下的，默认方式下开启了好多检查，又有一个到现在也没弄明白的一套rules，于是就出了这么多东西。于是我们把Data collection,API call reporting,Call validation,COM call reporting,COM object tracking,Deadlock analysis,.Net analysis,.Net call reporting,Resource tracking,全部关掉，只剩一个Memory Tracking，用来检查内存泄露，果然报错迅速减少，察看以后发现boundschecker还是有点乱报错，不都是我们想要的，索性不去管它，专心致志于memory leak。

咦？怎么没有内存泄露呢？怎么可能呢？找啊找，发现原来我没有开final check，这样从原理上讲，在系统运行期间分配了内存，但是在退出程序的时候可能没有释放，但是因为不做final check，所以根本不可能发现内存泄露，在程序运行期间，boundschecker 是不知道你是否要释放掉某一块空间的，事实上也不可能知道。

打开final check，突然发现程序启动不起来了，考验我的耐心？我等。功夫不负有心人，等了两个小时，画面终于出现了，只有2.2HZ，这显然是无法接受的。找原因…….找啊找，还是不知道。

这时候突然系统报告说磁盘空间已满，这显然是怪异的，我每个分区都至少有几个G的空间，怎么可能满呢?过去察看一下，发现在临时目录里边有个4个G的文件。idx10.tmp，nml1.tmp，stg11.tmp这三个文件就是boundschecker 做出来的，当时具体是哪个比较大记不清了，反正是其中一个将我的磁盘写满了。凭直觉我觉得这应该是一个boundschecker用来记录内存变化情况或者是相关信息的文件，好，那么就去该boundschecker的设置，我去掉了很多觉得无用的设置选项，再来，果然没有了，但是依然要等很长时间才能显示出来，而且帧数比较小。

再调，再调，怎么调都没有办法调得正常了，卸载重装，再卸再装，没有办法了，最后很无奈，我对boundschecker的使用以失败告终。