自制DynamicProxy开发成功,性能测试提升了1.4倍。(看来微软的realproxy并不弱!导致我无法提升一个数量级)
2010-06-05 07:52
393 查看
参考了微软的realproxy设计模式,使用相同的IMessage结构,重写了整个proxy。
使用了emit技术,性能得到了极大提升。
模仿旧的pojo代码,得到:
代码 //performance
public void test002()
{
IproxyWithProperty pojo = Pixysoft.Tools.PojoHelper.GetPojo<IproxyWithProperty>();
IproxyWithProperty proxy = new MyProxy<IproxyWithProperty>().Value;
Pixysoft.Tools.CodeTimer.Initialize();
Pixysoft.Tools.CodeTimer.Time("pojo", 100000, delegate()
{
pojo.Name = "123";
object name = pojo.Name;
});
Pixysoft.Tools.CodeTimer.Time("proxy", 100000, delegate()
{
proxy.Name = "123";
object name = proxy.Name;
});
}
测试结果如下:
------ Test started: Assembly: Pixysoft.Framework.Reflection.dll ------
pojo
Time Elapsed: 7,997ms
CPU time: 7,796,875,000ns
Gen 0: 760
Gen 1: 0
Gen 2: 0
proxy
Time Elapsed: 5,651ms
CPU time: 5,484,375,000ns
Gen 0: 398
Gen 1: 0
Gen 2: 0
1 passed, 0 failed, 0 skipped, took 13.77 seconds (Ad hoc).
性能提高了1.415倍。
如果把初始化proxy的代码放入循环,得到结果:
------ Test started: Assembly: Pixysoft.Framework.Reflection.dll ------
pojo
Time Elapsed: 8,569ms
CPU time: 8,015,625,000ns
Gen 0: 800
Gen 1: 0
Gen 2: 0
proxy
Time Elapsed: 6,263ms
CPU time: 5,843,750,000ns
Gen 0: 475
Gen 1: 0
Gen 2: 0
性能提高了1.368倍。
可以看出,微软的Realproxy本质上并不弱。 内部实现应该使用了类似emit的技术了。。。
因此,一天的努力几乎有点白费了。。。竟然没有提高一个数量级。。。
1 passed, 0 failed, 0 skipped, took 14.92 seconds (Ad hoc).
使用了emit技术,性能得到了极大提升。
模仿旧的pojo代码,得到:
代码 //performance
public void test002()
{
IproxyWithProperty pojo = Pixysoft.Tools.PojoHelper.GetPojo<IproxyWithProperty>();
IproxyWithProperty proxy = new MyProxy<IproxyWithProperty>().Value;
Pixysoft.Tools.CodeTimer.Initialize();
Pixysoft.Tools.CodeTimer.Time("pojo", 100000, delegate()
{
pojo.Name = "123";
object name = pojo.Name;
});
Pixysoft.Tools.CodeTimer.Time("proxy", 100000, delegate()
{
proxy.Name = "123";
object name = proxy.Name;
});
}
测试结果如下:
------ Test started: Assembly: Pixysoft.Framework.Reflection.dll ------
pojo
Time Elapsed: 7,997ms
CPU time: 7,796,875,000ns
Gen 0: 760
Gen 1: 0
Gen 2: 0
proxy
Time Elapsed: 5,651ms
CPU time: 5,484,375,000ns
Gen 0: 398
Gen 1: 0
Gen 2: 0
1 passed, 0 failed, 0 skipped, took 13.77 seconds (Ad hoc).
性能提高了1.415倍。
如果把初始化proxy的代码放入循环,得到结果:
------ Test started: Assembly: Pixysoft.Framework.Reflection.dll ------
pojo
Time Elapsed: 8,569ms
CPU time: 8,015,625,000ns
Gen 0: 800
Gen 1: 0
Gen 2: 0
proxy
Time Elapsed: 6,263ms
CPU time: 5,843,750,000ns
Gen 0: 475
Gen 1: 0
Gen 2: 0
性能提高了1.368倍。
可以看出,微软的Realproxy本质上并不弱。 内部实现应该使用了类似emit的技术了。。。
因此,一天的努力几乎有点白费了。。。竟然没有提高一个数量级。。。
1 passed, 0 failed, 0 skipped, took 14.92 seconds (Ad hoc).
相关文章推荐
- 为了给自己开发一个支持 fastcgi 的 http server 做准备。剥离了 nanoweb 的 fastcgi 接口部分代码。测试了下。 成功了
- 异常信息:CLR无法从COM 上下文0x645e18 转换为COM上下文0x645f88,这种状态已持续60秒。拥有目标上下文/单元的线程很有可能执行的是非泵式等待或者在不发送 Windows 消息的情况下处理一个运行时间非常长的操作.这种情况通常会影响到性能,甚至可能导致应用程序不响应或者使用的内存随时间不断累积
- 用python开发了一个简单apache web服务端范例,在win10 + apache2.4.9 + python3.5 测试成功
- 用python开发了一个简单apache web服务端范例,在win10 + apache2.4.9 + python3.5 测试成功
- 做一个开发人员认可的测试人员(系列6)-如何使得机器的性能相当
- 一个电商购物(B2C)网站性能测试需求
- 奶奶的熊,就是因为一跳串口线,导致一个客户重新做了一次S5pv210 底板,烧写wince6.0 两周不成功,哎,实在没办法,叫他发电路板给我调试,我发现居然是串口线!
- 今天下午做的一个关于web前端性能/性能测试的Talk
- 性能测试工具 nGrinder 项目剖析及二次开发
- Qt4.8.0+DirectFB1.4.12开发环境的搭建(测试成功)
- 基于WebService的性能测试脚本开发
- 一个C语言开发的炸金花纸牌游戏附带vs性能分析报告
- jQuery插件开发精品教程,让你的jQuery提升一个台阶
- Android应用开发之性能测试之TraceView
- 提升Android应用开发性能的十大要点(1)
- 小米Adnroid默认禁止悬浮框的使用,导致开发的悬浮框无法接收事件
- Apache作为负载均衡器的一个配置问题导致的无法启动
- C#提升性能"数据库连接打开与关闭"经验分享(附:优化过的DBHelper类) 之配餐系统的开发
- ZooKeeper的一个性能测试
- 程序开过多线程,导致hadoop作业无法运行成功——Call to hadoop1:9000 failed on lo cal exception: java.io.IOException: Coul