This project is read-only.

Startup Time

Aug 30, 2010 at 12:04 AM

Anyone got any ideas why the Calcium startup time has increased since the last few checkins.  Go back 3-4 checkins and it is pretty quick.  Now it is much slower.  Not quite sure why.

Coordinator
Aug 30, 2010 at 9:35 AM

Looks like we'll need to do some profiling. If anyone would like to do some investigating I would be greatly appreciative.

Aug 30, 2010 at 8:58 PM

Never done any profiling so will see what I can learn online.

It has to be something obvious though as startup time has gone from a few seconds to 40s just to start your sample.  I remember I was able to go a version back and everything was fine just to prove it wasn't a machine issue.

Will report anything I find back here.  Would appreciate comments from anyone else using Calcium too.

Aug 31, 2010 at 7:14 AM

The slowdown first started in changeset 67366.

Aug 31, 2010 at 2:19 PM
Edited Aug 31, 2010 at 2:20 PM

OK,

Got the startup time back down to 8s from 40+ with the sample.  As you will see from the code below that the more modules you have the worse the problem becomes.  In my production project I have 18 distinct modules.

I narrowed the delay to what I thought was within CustomModuleInitializer  (Source\Calcium\Calcium\Calcium.Client\Modularity\CustomModuleInitializer.cs)

If you comment out the output event then it works as normal.  (well 12s startup anyway)

 

protected override IModule CreateModule(string typeName)
{
var eventAggregator = serviceLocator.GetInstance<IEventAggregator>();
var outputPostedEvent = eventAggregator.GetEvent<OutputPostedEvent>();
//outputPostedEvent.Publish(new OutputMessage { Message = "Initializing module " + typeName });

var result = base.CreateModule(typeName);

var moduleInitializedEvent = eventAggregator.GetEvent<ModuleCreatedEvent>();
moduleInitializedEvent.Publish(result);

return result;
}

 

I tried stopping the output module from subscribing to events as a test (with the event being published) although that made no speed difference.  The problem seemed to be with publishing the event. 

I then checked to see if anywhere else was subscribing to the event.  The splash screen is.

Source\Calcium\Calcium\Calcium.Client\Gui\Controls\SplashScreen\SplashScreenViewModel.cs

 

void OnOutputPosted(OutputMessage obj)
{
Dispatcher.InvokeIfRequired(() => Messages.Add(obj));
Thread.Sleep(3000);
}

Yuk, a horrible sleep for 3 seconds. and another 300ms within WaitForEventAggregator.

 

 

void WaitForEventAggregator()
{
bool eventSubscribed = false;
while (!eventSubscribed)
{
if (ServiceLocatorSingleton.Instance.IsInitialized())
{
IEventAggregator eventAggregator;
eventSubscribed = ServiceLocatorSingleton.Instance.TryGetInstance<IEventAggregator>(out eventAggregator);
if (eventSubscribed)
{
var outputEvent = eventAggregator.GetEvent<OutputPostedEvent>();
outputEvent.Subscribe(OnOutputPosted);
break;
}
}
Thread.Sleep(300);
}
}

 

By commenting out the 3s sleep startup is now 8 seconds.   Everything else was put back to latest changeset to ensure that was the only change required.  The 300ms sleep is required else the app will hang

Result!  A lunch break well spent.

Coordinator
Aug 31, 2010 at 2:53 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Aug 31, 2010 at 2:54 PM

Thanks for locating the issue James! Looks like some test code wasn't removed.

 

Cheers,

Daniel