Zmud/Cmud两种复杂数据类型的性能测试
今天测试了一下结构列表和结构嵌套（值是一个复杂结构，键是table中的唯一主键）这两种数据结构在Zmud/Cmud中使用的性能。 结构列表就是一个列表，但是列表中的元素是一个复杂结构。比如"id=5|name=中央广场"|"id=4|name=西大街"就是一个标准的结构列表，里面有两个元素：id=5|name=中央广场、id=4|name=西大街。这样子的结构和一般SQL里面的表的结构比较雷同。结构嵌套是结构嵌套结构，比如4="id=4|name=西大街"|5="id=5|name=中央广场"，就是这样子的一种结构嵌套。
这两种结构都是我用来表示一组房间信息的数据类型，现在测试一下那种数据类型在做搜索的时候数据更快一点。我用了下面的脚本：
#show %time("hh:nn:ss:zzz")
#local $batch
$batch=@batch_room2("zoneid=1")
#loop 20 {
#show %db(%db($batch,%i),name)
}
#show %time("hh:nn:ss:zzz")
测试结构嵌套的消耗时间，用下面的脚本
#show %time("hh:nn:ss:zzz")
$batch=@batch_room_info("zoneid=1")
#loop 20 {
#show %db(@singleRecordSearch($batch,id,%i),name)
}
#show %time("hh:nn:ss:zzz");
测试结构列表的消耗时间，其中@batch_room2函数是从数据库里面按照输入条件查询出结构嵌套组织的房间信息集合，@batch_room_info是从数据库里面按照输入条件查询出结构列表组织的房间信息。@singleRecordSearch函数是我自己写的一个结构列表搜索函数，就是一个#forall $list，然后对每个元素取出key对应的值和搜索值进行比较，一样就返回那个结构。zoneid=1是扬州区域。返回结构如下：
结构嵌套执行的时间记录：（一共487毫秒）
16:30:57:802
西门
西大街
西大街
西大街
中央广场
东大街
东大街
东大街
东门
北大街
北大街
北门
南大街
南大街
南大街
南门
云台街
云台街
云台街
花园别墅区
16:30:58:289
结构列表执行的时间：（一共372毫秒）
16:30:58:289
西门
西大街
西大街
西大街
中央广场
东大街
东大街
东大街
东门
北大街
北大街
北门
南大街
南大街
南大街
南门
云台街
云台街
云台街
花园别墅区
16:30:58:661
-----------------------------------------------------------
第二次执行时间分别是495毫秒和348毫秒
多次执行发现结果都是自己用#forall做遍历的结构列表搜索效率高于用record结构然后用默认%db函数进行搜索的效率。
修改测试代码如下，
#local $batch
$batch=@batch_room2("zoneid=1")
#show %time("hh:nn:ss:zzz")
#loop 20 {
#show %db(%db($batch,%i),name)
}
#show %time("hh:nn:ss:zzz")
$batch=@batch_room_info("zoneid=1")
#show %time("hh:nn:ss:zzz")
#loop 20 {
#show %db(@singleRecordSearch($batch,id,%i),name)
}
#show %time("hh:nn:ss:zzz");
第一次结果是317毫秒和141毫秒，
第二次结构是310毫秒和174毫秒。
消除数据库查询的效率损失以后，发现两种方法之间效率差距在2：1左右。实在是出乎我的预料。我一直以为系统的函数效率
能够高于我自己写的简单#forall查询函数。
难道问题出在@singleRecordSearch函数因为知道是用id这个主键进行搜索，找到一个结果就#return上？如果按照这个理论
两者相率没有执行效率上没有本质区别，但是我根据实际情况作了算法优化导致效率差异。这更体现Zmud/Cmud软件本身核心
函数效率的局限性。 第三次测试稍微修改一下测试脚本：#local $batch
$batch=@batch_room2("zoneid=1")
#show %time("hh:nn:ss:zzz")
#loop 20 {
#show %db(@newDb($batch,%i),name)
}
#show %time("hh:nn:ss:zzz")
$batch=@batch_room_info("zoneid=1")
#show %time("hh:nn:ss:zzz")
#loop 20 {
#show %db(@singleRecordSearch($batch,id,%i),name)
}
#show %time("hh:nn:ss:zzz");
其中函数@newDb效果和%db类似，只是我用#loopdb重写了一下，也是发现一个值就返回结果退出。这次执行结果又不一样了。
第一次结果是53毫秒和117毫秒
第二次结果是55毫秒和120毫秒
看来还是结构嵌套的效率更高一点。效果大概是结构列表效率的2倍左右。不过相关搜索函数需要自己用#loopdb重写一下，否则
直接用系统的%db肯定不会满足你的效率要求的。
[ 本帖最后由 seagate 于 2010-3-8 05:00 PM 编辑 ] good job......
页:
[1]