Hi! Weld folks, I need some help with a micro benchmark: You know we've talked about disk footprint in SE, so I hacked together a small microbenchmark and as a side effect we also got what is really needed to have CDI running https://github.com/struberg/cdi-performance I'm curious about missing some dependency excludes for Weld. could you please run $> mvn clean dependency:copy-dependencies -DincludeScope=compile -PWeld -Dweld.version=2.2.5.Final $> ls -al target/dependency/ and tell me which dependencies can be without having some CDI functionality missing? Feel free to pimp the pom and ship a pull request. txs and LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

Hi! Weld folks, I need some help with a micro benchmark: You know we've talked about disk footprint in SE, so I hacked together a small microbenchmark and as a side effect we also got what is really needed to have CDI running https://github.com/struberg/cdi-performance I'm curious about missing some dependency excludes for Weld. could you please run $> mvn clean dependency:copy-dependencies -DincludeScope=compile -PWeld -Dweld.version=2.2.5.Final $> ls -al target/dependency/ and tell me which dependencies can be without having some CDI functionality missing? Feel free to pimp the pom and ship a pull request. txs and LieGrue, strub _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

On Tuesday, 21 October 2014, 14:07, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: > Btw I've run your benchmark locally and observed the following results: OWB 1.2.6: 9827ms Weld 2.2.5.Final: 20ms ;-) I did however tweak the test a bit so that Weld's optimizations can be leveraged[1]. I admit that in certain situations (like your test without my change) Weld performs worse than it should and this is a good input for us. As for the NPE you observed not sure what is going on there. Perhaps WeldContextControl implementation in DeltaSpike is not really thread safe? Jozef [1] https://github.com/jharting/cdi-performance/commits/weld On 10/21/2014 01:43 PM, Jozef Hartinger wrote: > Hi Mark, > > thanks for showcasting your new feature. Great to see OWB getting > faster! As for the micro benchmark I suggest that you check out JMH[1]. > > If you need an input from the Weld team, use weld-dev(a)lists.jboss.org > > [1] http://openjdk.java.net/projects/code-tools/jmh/ > > On 10/21/2014 11:59 AM, Mark Struberg wrote: >> Hi! >> >> Weld folks, I need some help with a micro benchmark: >> >> You know we've talked about disk footprint in SE, so I hacked together a small microbenchmark and as a side effect we also got what is really needed to have CDI running >> >> https://github.com/struberg/cdi-performance >> >> I'm curious about missing some dependency excludes for Weld. >> >> could you please run >> >> $> mvn clean dependency:copy-dependencies -DincludeScope=compile -PWeld -Dweld.version=2.2.5.Final >> $> ls -al target/dependency/ >> >> and tell me which dependencies can be without having some CDI functionality missing? >> >> Feel free to pimp the pom and ship a pull request. >> >> >> txs and LieGrue, >> strub >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

On Tuesday, 21 October 2014, 14:56, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: > For certain combinations of scopes this is a perfectly legal optimization ;-) It's even mentioned in the spec (see 6.5.5). On 10/21/2014 02:46 PM, Mark Struberg wrote: > Folks, you really scare me a bit! > > I debugged into it and for the first BeanManger#getReference I get a proxy. > > But for all other BeanManager#getReference I get the bare metal SimpleBeanWithoutInterceptor WITHOUT ANY PROXY. > Can you confirm this? > If so, then please tell me how you make this Serializable if it gets stored e.g in a Http Session? > > > This is just not conform to the CDI spec I fear. I even consider this a blocker bug... > > LieGrue, > strub > > > >> On Tuesday, 21 October 2014, 14:07, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: >>> Btw I've run your benchmark locally and observed the following results: >> OWB 1.2.6: 9827ms >> Weld 2.2.5.Final: 20ms >> >> ;-) >> >> I did however tweak the test a bit so that Weld's optimizations can be >> leveraged[1]. I admit that in certain situations (like your test without >> my change) Weld performs worse than it should and this is a good input >> for us. >> >> As for the NPE you observed not sure what is going on there. Perhaps >> WeldContextControl implementation in DeltaSpike is not really thread safe? >> >> Jozef >> >> [1] https://github.com/jharting/cdi-performance/commits/weld >> >> On 10/21/2014 01:43 PM, Jozef Hartinger wrote: >>> Hi Mark, >>> >>> thanks for showcasting your new feature. Great to see OWB getting >>> faster! As for the micro benchmark I suggest that you check out JMH[1]. >>> >>> If you need an input from the Weld team, use weld-dev(a)lists.jboss.org >>> >>> [1] http://openjdk.java.net/projects/code-tools/jmh/ >>> >>> On 10/21/2014 11:59 AM, Mark Struberg wrote: >>>> Hi! >>>> >>>> Weld folks, I need some help with a micro benchmark: >>>> >>>> You know we've talked about disk footprint in SE, so I hacked >> together a small microbenchmark and as a side effect we also got what is really >> needed to have CDI running >>>> https://github.com/struberg/cdi-performance >>>> >>>> I'm curious about missing some dependency excludes for Weld. >>>> >>>> could you please run >>>> >>>> $> mvn clean dependency:copy-dependencies -DincludeScope=compile >> -PWeld -Dweld.version=2.2.5.Final >>>> $> ls -al target/dependency/ >>>> >>>> and tell me which dependencies can be without having some CDI >> functionality missing? >>>> Feel free to pimp the pom and ship a pull request. >>>> >>>> >>>> txs and LieGrue, >>>> strub >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided >> on this list, the provider waives all patent and other intellectual property >> rights inherent in such information. >> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >>> Note that for all code provided on this list, the provider licenses the >> code under the Apache License, Version 2 >> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided >> on this list, the provider waives all patent and other intellectual property >> rights inherent in such information. >>

hmm should it pass TCKs then? ;) /me is joking Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2014-10-21 15:24 GMT+02:00 Mark Struberg <struberg(a)yahoo.de&gt;: > Hi! > > Yes, I missed that you changed the test target. It is now not testing proxies but how fast ApplicationScoped beans injected into other ApplicationScoped beans work. > > I agree that this might be a valid performance optimisation, but people should be aware that this is done. Have seen quite a few 'ServiceHolder' with getters to the actual services in projects where CDI gets used in companion with legacy frameworks. > > I will add this as another use case to the test suite. > > LieGrue, > strub > > > > >> On Tuesday, 21 October 2014, 14:56, Jozef Hartinger < jharting(a)redhat.com&gt; wrote: >> > For certain combinations of scopes this is a perfectly legal >> optimization ;-) It's even mentioned in the spec (see 6.5.5). >> >> >> On 10/21/2014 02:46 PM, Mark Struberg wrote: >>> Folks, you really scare me a bit! >>> >>> I debugged into it and for the first BeanManger#getReference I get a proxy. >>> >>> But for all other BeanManager#getReference I get the bare metal >> SimpleBeanWithoutInterceptor WITHOUT ANY PROXY. >>> Can you confirm this? >>> If so, then please tell me how you make this Serializable if it gets stored >> e.g in a Http Session? >>> >>> >>> This is just not conform to the CDI spec I fear. I even consider this a >> blocker bug... >>> >>> LieGrue, >>> strub >>> >>> >>> >>>> On Tuesday, 21 October 2014, 14:07, Jozef Hartinger >> <jharting(a)redhat.com&gt; wrote: >>>>> Btw I've run your benchmark locally and observed the following >> results: >>>> OWB 1.2.6: 9827ms >>>> Weld 2.2.5.Final: 20ms >>>> >>>> ;-) >>>> >>>> I did however tweak the test a bit so that Weld's optimizations can >> be >>>> leveraged[1]. I admit that in certain situations (like your test >> without >>>> my change) Weld performs worse than it should and this is a good input >>>> for us. >>>> >>>> As for the NPE you observed not sure what is going on there. Perhaps >>>> WeldContextControl implementation in DeltaSpike is not really thread >> safe? >>>> >>>> Jozef >>>> >>>> [1] https://github.com/jharting/cdi-performance/commits/weld >>>> >>>> On 10/21/2014 01:43 PM, Jozef Hartinger wrote: >>>>> Hi Mark, >>>>> >>>>> thanks for showcasting your new feature. Great to see OWB getting >>>>> faster! As for the micro benchmark I suggest that you check out >> JMH[1]. >>>>> >>>>> If you need an input from the Weld team, use >> weld-dev(a)lists.jboss.org >>>>> >>>>> [1] http://openjdk.java.net/projects/code-tools/jmh/ >>>>> >>>>> On 10/21/2014 11:59 AM, Mark Struberg wrote: >>>>>> Hi! >>>>>> >>>>>> Weld folks, I need some help with a micro benchmark: >>>>>> >>>>>> You know we've talked about disk footprint in SE, so I >> hacked >>>> together a small microbenchmark and as a side effect we also got what >> is really >>>> needed to have CDI running >>>>>> https://github.com/struberg/cdi-performance >>>>>> >>>>>> I'm curious about missing some dependency excludes for >> Weld. >>>>>> >>>>>> could you please run >>>>>> >>>>>> $> mvn clean dependency:copy-dependencies >> -DincludeScope=compile >>>> -PWeld -Dweld.version=2.2.5.Final >>>>>> $> ls -al target/dependency/ >>>>>> >>>>>> and tell me which dependencies can be without having some CDI >>>> functionality missing? >>>>>> Feel free to pimp the pom and ship a pull request. >>>>>> >>>>>> >>>>>> txs and LieGrue, >>>>>> strub >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>>>> Note that for all code provided on this list, the provider >> licenses the >>>> code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided >>>> on this list, the provider waives all patent and other intellectual >> property >>>> rights inherent in such information. >>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider >> licenses the >>>> code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >> provided >>>> on this list, the provider waives all patent and other intellectual >> property >>>> rights inherent in such information. >>>> >> > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 ( http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.

On Friday, 5 December 2014, 16:50, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: > Actually, I was wrong. This *is* a valid optimization for CDI 1.0. It however *is not valid* for CDI 1.1+ as it breaks AlterableContext.destroy(). This is fixed in Weld 2.2.7.Final http://weld.cdi-spec.org/download/ On 10/21/2014 02:56 PM, Jozef Hartinger wrote: > For certain combinations of scopes this is a perfectly legal > optimization ;-) It's even mentioned in the spec (see 6.5.5). > > On 10/21/2014 02:46 PM, Mark Struberg wrote: >> Folks, you really scare me a bit! >> >> I debugged into it and for the first BeanManger#getReference I get a proxy. >> >> But for all other BeanManager#getReference I get the bare metal SimpleBeanWithoutInterceptor WITHOUT ANY PROXY. >> Can you confirm this? >> If so, then please tell me how you make this Serializable if it gets stored e.g in a Http Session? >> >> >> This is just not conform to the CDI spec I fear. I even consider this a blocker bug... >> >> LieGrue, >> strub >> >> >> >>> On Tuesday, 21 October 2014, 14:07, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: >>>> Btw I've run your benchmark locally and observed the following results: >>> OWB 1.2.6: 9827ms >>> Weld 2.2.5.Final: 20ms >>> >>> ;-) >>> >>> I did however tweak the test a bit so that Weld's optimizations can be >>> leveraged[1]. I admit that in certain situations (like your test without >>> my change) Weld performs worse than it should and this is a good input >>> for us. >>> >>> As for the NPE you observed not sure what is going on there. Perhaps >>> WeldContextControl implementation in DeltaSpike is not really thread safe? >>> >>> Jozef >>> >>> [1] https://github.com/jharting/cdi-performance/commits/weld >>> >>> On 10/21/2014 01:43 PM, Jozef Hartinger wrote: >>>> Hi Mark, >>>> >>>> thanks for showcasting your new feature. Great to see OWB getting >>>> faster! As for the micro benchmark I suggest that you check out JMH[1]. >>>> >>>> If you need an input from the Weld team, use weld-dev(a)lists.jboss.org >>>> >>>> [1] http://openjdk.java.net/projects/code-tools/jmh/ >>>> >>>> On 10/21/2014 11:59 AM, Mark Struberg wrote: >>>>> Hi! >>>>> >>>>> Weld folks, I need some help with a micro benchmark: >>>>> >>>>> You know we've talked about disk footprint in SE, so I hacked >>> together a small microbenchmark and as a side effect we also got what is really >>> needed to have CDI running >>>>> https://github.com/struberg/cdi-performance >>>>> >>>>> I'm curious about missing some dependency excludes for Weld. >>>>> >>>>> could you please run >>>>> >>>>> $> mvn clean dependency:copy-dependencies -DincludeScope=compile >>> -PWeld -Dweld.version=2.2.5.Final >>>>> $> ls -al target/dependency/ >>>>> >>>>> and tell me which dependencies can be without having some CDI >>> functionality missing? >>>>> Feel free to pimp the pom and ship a pull request. >>>>> >>>>> >>>>> txs and LieGrue, >>>>> strub >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided >>> on this list, the provider waives all patent and other intellectual property >>> rights inherent in such information. >>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>> code under the Apache License, Version 2 >>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided >>> on this list, the provider waives all patent and other intellectual property >>> rights inherent in such information. >>> > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.