I started looking at this and did a quick test.

I found that if I enable the ctkSimplePython shell in the ctk build and then launch it with a simple startup script I can get an image display in about 3 seconds (includes time to import vtk, slicer, qt into python, plus loading the volume).

But if I bring up slicer on the same machine it takes about 15 seconds, not including time to load volume.

This test was done on a mac mini with a debug build of slicer.

Command line:

% ./Slicer-build/Slicer --launcher-no-splash --launch CTK-build/CTK-build/bin/ctkSimplePythonShell ~/Dropbox/hacks/slicer/slite.py

Contents of slite.py

print('start')
modules = ('os', 'sys', 'vtk', 'qt', 'slicer','vtkSlicerVolumesModuleLogic')

for m in modules:
exec('import %s' % m)
print('imported %s' % m)

mrmlScene = slicer.vtkMRMLScene()
appLogic = slicer.vtkSlicerApplicationLogic()
sliceWidget = slicer.qMRMLSliceWidget()

volumesLogic = vtkSlicerVolumesModuleLogic.vtkSlicerVolumesLogic()
volumesLogic.SetMRMLScene(mrmlScene)
volumesLogic.AddArchetypeScalarVolume('/Users/pieper/data/MR-head.nrrd', 'MR-head', 0, None)

sliceWidget.setMRMLScene(mrmlScene)
sliceWidget.show()

Here's an experimental branch to move module loading out of the 'splash screen' phase of the start up process:

https://github.com/pieper/Slicer/commits/defer-module-loading

This works, in the sense that the GUI appears quickly. But then as expected it freezes while the module discovery process goes on.

What needs to happen next is to move the module discovery into threads.

Care will need to be taken on several fronts:

• the module discovery in the threads must not trigger non-thread-safe code in the main thread (i.e. no Rendering or GUI updates)

• the command line options to load data are the key elements that should be sped up by this process, so we need to be sure volume loading and display can happen before module discovery completes. This should be fine, since reading is handled at the MRML level and the Volumes module is not required. The IO code needs to be checked to confirm that this works.

• Running CLI modules should be easy to do in a thread. For shared libraries I haven't found any documentation or other reason to believe that loading a shared library in a thread would be problematic - the loaded entry points should become available to the main thread. This needs to be confirmed on all platforms.

• We should provide a property (or signal) on the main application instance indicating that the loading has completed. This way python scripts passed on the command line can be triggered after the module loading is completed. This will be important for things like python ctests where the operation is defined as a command line argument to slicer.

Excellent.

Is this something you plan on completing ? A prototype implementation to get a better understanding about the pros and cons of the approach ?

I might work on it now and then as time permits -- I tend to get motivated for it while waiting for slicer to startup :P

But I wanted to put this into the bug report so that if someone else can spend some time on it (perhaps as part of the end-of-year work for NAC) they will have some idea where to start. The nice thing about this project is that a programmer could work on it without really needing to know much about medical imaging or about how slicer works in general.

Make sens. Yeapp it is indeed a fun topic to tackle :)