本文测试远程调用以下对象时的执行速度:
场景是这样的:客户端获取服务端,把自己注册给服务端,然后服务端回调客户端,并传递上述的对象。
代码下载
https://www.box.com/s/lai03ktzdi0gzo5tlv63
https://skydrive.live.com/embed?cid=7EA5197BBA7EBC13&resid=7EA5197BBA7EBC13%21146&authkey=AL6R0X8DgUO8vSk
https://docs.google.com/open?id=0B92-FAjNvVzGX2lMUFliZkl5Qk0
输出单次时间(20次) | |||
首次传输用时 | 后续传输用时 | 服务端总用时 | |
无属性的MBR | 62 | 0 | 128 |
50个属性的MBR | 62 | 0 | 125 |
空序列化对象 | 62 | 0 | 124 |
50个属性的序列化对象 | 47 | 0 | 117 |
不输出单次时间+release版+优化(4000次) | |||
一次性运行 | 分别运行 | ||
无属性的MBR | 2830 | 2794 | |
50个属性的MBR | 2762 | 2727 | |
空序列化对象 | 2132 | 2203 | |
50个属性的序列化对象 | 3036 | 3094 |
在输出单次时间的测试中,可以发现第一次连接用时总是比较长,几乎稳定为62毫秒。可能是为了输出时间,我调用DateTime.Now的关系。
在后面的release测试中,一次性运行就是开一个服务端,开一个客户端,这个服务端一次性把四个测试全运行了。调整代码后我发现,第一次MBR测试总是比第二次慢六十几毫秒,不论第一次是无属性MBR还是50属性MBR。这说明第一次封送MBR时,可能把应用程序域里其他的MBR也处理了一下,所以慢。所以,我又分别运行了这四个测试。
结果表明,MBR无论多少个属性,传送时间都是固定的。
传送空序列化对象比无属性MBR快了约26%。序列化对象的属性增加了,序列化时间也增加了。如果序列化对象的属性数量,和序列化所需时间是正比的话,那么大约每个属性花17.82毫秒,如果一个对象有超过33个属性,可以考虑用MBR。
当然了,如果后续还有方法调用,MBR可能效率就比较低了,因为计算所用的参数还要传回服务器,服务器结果还要返回客户端。