JBoss development,
A new message was posted in the thread "Profiling the dependency project":
http://community.jboss.org/message/525047#525047
Author : Kabir Khan
Profile :
http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Since the indexing dependency resolver I have been working on does not yield the
performance improvements I was hoping for, I am now benchmarking the dependency project in
isolation. It makes profiling a lot easier since there is a lot less other things going on
which is the case when starting up the application server. My thinking now is that we
should do the same for the other MC modules.
One thing is to not try to resolve contexts that are in the INSTALLED state (or where the
, from AbstractController.resolveContexts(boolean), this shaves off about 20% for contexts
installed in the right order. See
http://community.jboss.org/message/524747#524747 for a
description of the benchmark.
for (ControllerState fromState : stateModel)
{
ControllerState toState = stateModel.getNextState(fromState);
- if (resolveContexts(fromState, toState, trace))
+
+ if (stateModel.isValidState(toState))
{
- resolutions = true;
- break;
+ if (resolveContexts(fromState, toState, trace))
+ {
+ resolutions = true;
+ break;
+ }
}
}
}
Another simple thing that cuts deploying 2000 contexts
-with dependencies in the right order from 852ms->789ms
-with dependencies in the right order from 12788ms->8320ms
is to further modify resolveContexts to not break out of the loop once it resolves some
contexts for a state, e.g.
boolean resolutions = true;
while (resolutions || onDemandEnabled)
{
if (onDemandEnabled)
wasOnDemandEnabled = true;
onDemandEnabled = false;
resolutions = false;
for (ControllerState fromState : stateModel)
{
ControllerState toState = stateModel.getNextState(fromState);
if (stateModel.isValidState(toState))
{
if (resolveContexts(fromState, toState, trace))
{
resolutions = true;
// break; // Don't exit here
}
}
}
}
Profiling this for 500 contexts reduces the number of calls to the nested resolveContexts
from
-17,500 to 7000 (right order)
-17,500 to 10,493 (wrong order), a bit down the line we end up with 377K instead of 627K
calls to resolveDependencies()
All tests pass apart from the ones mentioned in
http://community.jboss.org/message/524862#524862 which I know how to fix if Ales agrees:
mailto:kabir.khan@jboss.com wrote:
I mean this:
*public* *void* testPlainLifecycleDependencyWrongOrder() *throws* Throwable
{
plainLifecycleDependencyWrongOrder();
ControllerContext context2 = assertInstall(1, "Name2",
ControllerState.+CONFIGURED+);
ControllerContext context1 = assertInstall(0, "Name1");
+assertEquals+(ControllerState.+INSTALLED+, context2.getState());
SimpleBeanWithLifecycle bean1 = (SimpleBeanWithLifecycle) context1.getTarget();
+assertNotNull+(bean1);
SimpleBeanWithLifecycle bean2 = (SimpleBeanWithLifecycle) context2.getTarget();
+assertNotNull+(bean2);
+assertEquals+(1, bean1.createOrder);
+assertEquals+(2, bean2.createOrder);
+assertEquals+(3, bean1.startOrder);
+assertEquals+(4, bean2.startOrder);
}
The new resolver works with
+assertEquals+(1, bean1.createOrder);
+assertEquals+(2, bean1.startOrder);
+assertEquals+(3, bean2.createOrder);
+assertEquals+(4, bean2.startOrder);
The actual hardcoded orders of beans 1 and 2 is an implemetation detail as I see it. The
real check is making sure that the initial install of context 2 does not go beyond
CONFIGURED and:
bean1.startOrder > bean1.createOrder
bean2.startOrder > bean2.createOrder
bean2.createOrder > bean1.createOrder
bean2.startOrder > bean1.startOrder
I've got an infinite loop in the indexing resolver when I start up AS which I need to
fix before I can get any measurements of boot time, although it sounds like we won't
gain much from this.
--------------------------------------------------------------
To reply to this message visit the message page:
http://community.jboss.org/message/525047#525047