IoC容器的prototype性能测试

很有意思的测试,好奇之下,发现如果spring选择不支持PropertyEditor的话(spring创建出来的bean会不会是残废的就不知道了:D ),在without inject这个测试中,可以有4倍左右的提升.
因为spring在创建每个实例时都创建一个BeanWrapperImpl,这个东东又创建几十个Editro实例

一直都觉得PropertyEditor这东西不是特别好用。

效率差，每回都要"newInstance()"一下。

然后还没有状态，要状态最多只能用thread local的全局变量。差劲儿。

我又优化了一下，Nuts只要不集成spring的factory bean，每一个指标都基本保持在spring的10倍左右。（差别最小的singleton，Nuts比spring快3-10倍）

我前面比较的是Spring1.1.4。今天下载了spring 1.2.6。
测了一下，发现1.2.6比1.1.4还要慢。Nuts和Spring的最大效率差达到30倍。

我把测试结果总结在这里：
http://www.iteye.com/pages/viewpage.action?pageId=786

你说的很对,JADE container的架构和Pico是一样的，自己定义的CA可以和Pico的那些DefaultCA混合使用，所以只要切换到DefaultConstructorInjectionCA,容器的表现就和Pico完全一样了，当然，效率就有所降低了。

人人面前有一个天平，在这里，左边是convention,右边是configuration，倾向那一边都没有问题，只要保证天平的游标是可以活动的就行。这也是设计一个框架时候需要考虑的基本问题之一。

但是我一直人为一个好的框架,除了能够应对复杂的场合,更应该在适当的条件下,可以蜕化到最简单的状态. 拿container创建bean这种情况来看, 它可以是很复杂的,比如:先weave AOP aspects,然后CDI,然后SDI,然后Post initialization.  也有可能是简单到仅仅是调用一个ctor。我就希望我的容器如果碰到后者这样的情况的时候，真正执行的代码效率就能够接近或者等同于直接用new一个object，这也是Jade Container 创建简单bean这么快的原因。

我可以让container去负责一个web framework的action的实例创建，而可以几乎不考虑创建对象的效率问题．

我对容器的需求不仅仅是简单的IoC，至少还需要提供AOP服务，在一个复杂业务系统中，Domain Object很有可能是一个有状态，享受了IoC，并且Aspectized的bean．所以在JADE-Container中针对创建bean/aspectized bean without injection进行了特别优化，并且达到了令我自己满意的效果（在我的机器上，Spring是5,515.263 calls/s，Jade Container的数据是1,210,653.753 calls/s，CGLib,赞一个   ）。

对了，不知道ajoo测试机器的配置及环境是？

jade的without injection的效率达到spring的30倍。在我发布的测试结果中，Nuts的效率也达到了Spring的30倍。

刚刚又做了一点优化，对无参数构造函数的情况，已经可以达到Spring的60倍。

是Class.forName("Bar").newInstance(null)"的八倍，"Bar.class.newInstance()"的二分之一，是"constructor.newInstance(null)"的三分之一到二分之一，是"new Bar()"的二十分之一。

CDI, SDI方面，jade的指标是Spring的10倍，在我的测试中,Nuts可以分别达到Spring的29倍和14倍。


至于aop，我不想重造轮子。等着集成一个好的aop实现进来呢。还是饭来张口舒服啊！:)

如果你有兴趣，可以大致介绍一下你的aop方案。听你说的效率，有点眼热。如果足够通用的话，我倒是挺想把你的方案集成进Nuts的。是用aspectwerkz么？



我的机器有1G内存，Pentium M 1.3G。不过我开了很多窗口，firefox占了不少内存的。

对了，Jade是基于pico的么？但是pico的灵活性不大好啊。


（其实，这个帖子应该挪到IOC班啊）

w/o injection, JADE 比 Spring快 1,210,653.753/5,515.263 = 220倍
其实纯粹的比较速度是没有太大的意义的, 只要框架能够满足具体应用的性能要求,那就够了.
当然,而如果在不影响功能的前提下, 能够免费的获得性能的提升,我相信大多数的框架使用者都是很乐意接受的.


pico配置灵活性能主要依靠nano container来完成的.我几乎把他的ComponentAdapter完全重写了,而container层次树及bean lifecycle management则沿用了pico的实现.

恩？不是1，865，671/66，555么？你贴的测试数据阿。


你是说aspectized？我说的是没有interceptor的数据。因为Nuts本身不提供aop方案，所以没法直接比较aspectized。集成spring的话，就跟它一样慢。所以才打你的aop方案的歪点子阿。:)


我说pico不好，不是说配置灵活性。而是说它的核心。主要就是指它的CA设计呆板。很多时候要象你一样重写，而不能重用。它的lifecycle管理也嫌不灵活。

是的。你的Nuts已经很快了，只要上了百万级，我相信已经可以应付绝大多数的应用了。呵呵，赞一个




我也认为pico不好，在Pico的眼里，似乎只有CDI才是正宗，这一点无论是从他的代码还是文档中都能看得出来。而且它的SDI的CA写得极其滥。所以一怒之下改写了CDI-CA/SDI-CA的代码，我让CDI-CA/SimpleCA变成核心的CA, SDI-CA/Caching-CA等变成了DecoratingCA，这样我就可以随意组合CA，同时进行CDI和SDI.



至于aop方案，我也是对Spring AOP实在是忍无可忍了才重写的。我的AOP方案必须依赖容器来创造aspect实例，因此不能单独脱离容器而存在，在目前的实现中，底层实现依赖于PicoContainer这个接口。

这样的design decision是有原因的，目的是为了实现Aspect重用，关于这个讨论，最早可以追溯到potian的blog中某篇文章，而前几天在JavaEye上也有讨论，只是看的人多，说的人少，不谈也罢。

我的AOP框架在Aspect weaving上，很大程度的参考了Shenli的JoyAOP实现(又要赞一个 写得好！) 。大家可以在SF上找到他的代码。
从功能上来说Aspectwerkz不知道强大了多少倍，所以整合AW也是我的下一个目标。但是目前情况来看，我的框架够用了，也懒得去动手了。

唯一要要赞一下自己框架的，就是配置文件。又是一个忍无可忍的产物，
自己动手丰衣足食阿。

<container name="testContainer">
  <components>
    <component key="test.model.Foo" class="test.model.FooImpl" scope="instance" />
    <component key="test.model.Bar" class="test.model.Bar" scope="instance" />
    <component key="test.model.Soo" class="test.model.Soo" scope="instance" />
  </components>
  
  <aspects>
    <pointcut classPattern=".*" methodPattern="noop">
      <interceptor-ref>fooInterceptor</interceptor-ref>
    </pointcut>
  </aspects>
  
  <advices>
    <interceptor key="fooInterceptor" class="test.interceptor.FooInterceptor" default-scope="vm"/>	  
  </advices>
</container>

哪个讨论啊？给了连接？

你觉得你的aop为什么比spring快那么多呢？spring也是基于cglib的呀。难道你是用aspectj么？看你的方法可以动态配置pointcut，不象aspectj。

能分析一下么？

就方法的拦截而言,两者速度都是差不多的，这个从测试数据上也能看出来。但是我也很纳闷为什么Spring创建prototype bean proxy会这么慢.

而我所做的优化其实很简单,就是在bean注册到容器的时候,把所有事先可以做的事情(比如确定是否需要CDI/SDI,确定是否weave aspects...)都一并处理了. 这样在创建bean实例的时候就可以简单的仅仅是创建bean实例就可以了.
当然,事先织入的是advice的stub,在真正调用到这个advice的时候采用容器去初始化这些advice实例。