IBM AIX 服务器上
< 一 > 利用 SUBSQL 接口手工进行测试
----------<Some test Data>-----------------------------------------
1.Record(int4,char const*)
dbDatabase db(dbDatabase::dbAllAccess, 16*1024); // 96Mb page pool
Insert 50000 records,elapsed time: 1 seconds
Insert 100000 records,elapsed time: 2 seconds
insert 1000000 records,elapsed time: 9 seconds
Insert 10000000 records,elapsed time: 120 seconds
dbDatabase db(dbDatabase::dbAllAccess, 160*1024); // 960Mb page pool
Insert 50000 records,elapsed time: 1 seconds
Insert 100000 records,elapsed time: 1 seconds
Insert 1000000 records,elapsed time: 8 seconds
Insert 10000000 records,elapsed time: 124 seconds
dbDatabase db(dbDatabase::dbAllAccess, 160*1024); // 960Mb page pool
db.setConcurrency(10);
Insert 10000000 records,elapsed time: 116 seconds
然后导入数据（ INFO_GSM, BILL_DATA ， USER_SPECIAL_NUMBER ）【来源于 172.18.1.30 数据库】
Update 100000 records,elapsed time: 1 seconds
Update 1000000 records,elapsed time: 9 seconds
Query 1000000 records,elapsed time: 2 seconds （多重查询条件）
Query 10000000 records,elapsed time: 1 seconds （唯一值查询条件）
以上初略的数据可以看出来（服务器响应慢），其速度比普通磁盘数据库是高出至少一个数量级的。
< 二 > 代码测试（效率上基本不存在问题，主要是安全性能测试）
自编代码测试： FTP::172.18.34.168\/data0/ibas/jianguoh/fastdb/examples/FastdbTest.cpp
源码如右：
数据库文件： FTP::172.18.34.168\/data0/ibas/jianguoh/fastdb/ FastdbTest.fdb
1、 Complex and Large transaction processing
多次对于大规模的数据进行增，删，查，改后进行事务处理，没有发现异常。（跑的测试代码） ( 先查询，然后更改，然后插入部分记录，最后再有选择地删除部分数据 )
2、 Concurrent transaction’s Safe
Concurrent Threads can run safely in my lots of tests!( 一 Update 模式进程和大量 ReadOnly 模式线程（同一个进程）并发操作 )
< 三 > 因为对于开源代码测试我们没有任何规范和流程，测试只能够依靠测试者自己当时的想法和定义来测
附：
本来就很好的内存机制，再加上多种高性能的查询优化技术，其效率应该是没什么问题了。
以下是一国外文献上更翔实直观的深度效率测试报告图：（其中 MS-SQL 指的是 Microsoft SQL Server 2000 磁盘数据库 ）
