5:44 p.m.
After doing some more profiling I think we can massively reduce startup time for a large
number of beans.
At the moment we add an @New bean for every managed bean, while according to the spec I
think this is only necessary for beans that are actually injected into an @New injection
point. I performed a quick test where I removed the @New beans (and skipped the tests) and
in the 5000 bean case it reduced the AS startup time form 90s to 60s (this is actually a
50% speedup as the AS takes 30s to start with a 5000 class deployment without weld), and
reduces the memory usage by a further 20Mb (bringing the total saving so far to 100Mb).
This speedup will probably be less for smaller deployment, because parts of the startup
process are O(n^2) on the number of beans (in particular TypeSafeResolver.findMatching).
Is my interpretation of the spec correct? The spec actually says that these @New beans
that do not match an injection point still exist but are disabled, which as far as I can
tell is the same as just not creating them.
Stuart
9:01 p.m.
I created a branch that changes this behaviour:
https://github.com/stuartwdouglas/core/tree/newbeans
However there are some TCK issues:
https://jira.jboss.org/browse/CDITCK-194
Stuart
On 14/11/2010, at 10:44 AM, Stuart Douglas wrote:
After doing some more profiling I think we can massively reduce
startup time for a large number of beans.
At the moment we add an @New bean for every managed bean, while according to the spec I
think this is only necessary for beans that are actually injected into an @New injection
point. I performed a quick test where I removed the @New beans (and skipped the tests) and
in the 5000 bean case it reduced the AS startup time form 90s to 60s (this is actually a
50% speedup as the AS takes 30s to start with a 5000 class deployment without weld), and
reduces the memory usage by a further 20Mb (bringing the total saving so far to 100Mb).
This speedup will probably be less for smaller deployment, because parts of the startup
process are O(n^2) on the number of beans (in particular TypeSafeResolver.findMatching).
Is my interpretation of the spec correct? The spec actually says that these @New beans
that do not match an injection point still exist but are disabled, which as far as I can
tell is the same as just not creating them.
Stuart
12:13 a.m.
You can still get a @New bean programmatically from the BM even if it's not
injected?
On Sun, Nov 14, 2010 at 1:44 AM, Stuart Douglas
<stuart.w.douglas(a)gmail.com>wrote:
After doing some more profiling I think we can massively reduce
startup
time for a large number of beans.
At the moment we add an @New bean for every managed bean, while according
to the spec I think this is only necessary for beans that are actually
injected into an @New injection point. I performed a quick test where I
removed the @New beans (and skipped the tests) and in the 5000 bean case it
reduced the AS startup time form 90s to 60s (this is actually a 50% speedup
as the AS takes 30s to start with a 5000 class deployment without weld), and
reduces the memory usage by a further 20Mb (bringing the total saving so far
to 100Mb). This speedup will probably be less for smaller deployment,
because parts of the startup process are O(n^2) on the number of beans (in
particular TypeSafeResolver.findMatching).
Is my interpretation of the spec correct? The spec actually says that these
@New beans that do not match an injection point still exist but are
disabled, which as far as I can tell is the same as just not creating them.
Stuart
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
---
Nik
12:18 a.m.
Not according to the spec.
Sent from my iPhone
On 14/11/2010, at 17:13, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
You can still get a @New bean programmatically from the BM even if
it's not injected?
On Sun, Nov 14, 2010 at 1:44 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com>
wrote:
After doing some more profiling I think we can massively reduce startup time for a large
number of beans.
At the moment we add an @New bean for every managed bean, while according to the spec I
think this is only necessary for beans that are actually injected into an @New injection
point. I performed a quick test where I removed the @New beans (and skipped the tests) and
in the 5000 bean case it reduced the AS startup time form 90s to 60s (this is actually a
50% speedup as the AS takes 30s to start with a 5000 class deployment without weld), and
reduces the memory usage by a further 20Mb (bringing the total saving so far to 100Mb).
This speedup will probably be less for smaller deployment, because parts of the startup
process are O(n^2) on the number of beans (in particular TypeSafeResolver.findMatching).
Is my interpretation of the spec correct? The spec actually says that these @New beans
that do not match an injection point still exist but are disabled, which as far as I can
tell is the same as just not creating them.
Stuart
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
---
Nik
3:38 a.m.
Correct, this got changed late on to allow us to do exactly this, but I guess I forgot
;-)
We should def do this, will pull and merge later.
BTW Stuart can you make sure you file JIRA issues for stuff like this for tracking (so the
release notes accurately reflect changes).
On 14 Nov 2010, at 06:18, Stuart Douglas wrote:
Not according to the spec.
Sent from my iPhone
On 14/11/2010, at 17:13, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
> You can still get a @New bean programmatically from the BM even if it's not
injected?
>
> On Sun, Nov 14, 2010 at 1:44 AM, Stuart Douglas <stuart.w.douglas(a)gmail.com>
wrote:
> After doing some more profiling I think we can massively reduce startup time for a
large number of beans.
>
> At the moment we add an @New bean for every managed bean, while according to the spec
I think this is only necessary for beans that are actually injected into an @New injection
point. I performed a quick test where I removed the @New beans (and skipped the tests) and
in the 5000 bean case it reduced the AS startup time form 90s to 60s (this is actually a
50% speedup as the AS takes 30s to start with a 5000 class deployment without weld), and
reduces the memory usage by a further 20Mb (bringing the total saving so far to 100Mb).
This speedup will probably be less for smaller deployment, because parts of the startup
process are O(n^2) on the number of beans (in particular TypeSafeResolver.findMatching).
>
> Is my interpretation of the spec correct? The spec actually says that these @New
beans that do not match an injection point still exist but are disabled, which as far as I
can tell is the same as just not creating them.
>
>
> Stuart
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
> --
> ---
> Nik
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
4926
days inactive
4927
days old
4 comments
3 participants
participants (3)
-
Nicklas Karlsson -
Pete Muir -
Stuart Douglas