Large slowdown of elastix_registration_method after reading a DICOM series

[N-Dekker]

Konstantinos (@ntatsisk) discovered that when a reasonably large DICOM series is read by itk.imread, it very much slows down a subsequent itk.elastix_registration_method call, even when the DICOM series is not used!

We did locally replace itk.imread by a "dummy" dummy_imread, as below here, and the negative speed effect was still there. So apparently it's something about the reader.Update() taking resources away.

def dummy_imread(filename):
    names_generator = itk.GDCMSeriesFileNames.New()
    names_generator.SetDirectory(f"{filename}")
    series_uid = names_generator.GetSeriesUIDs()
    reader = itk.ImageSeriesReader[itk.Image[itk.F, 3]].New()
    reader.SetFileNames(filenames)
    reader.Update()

The registration was of the following form, so it did not use DICOM at all:

fixed = itk.imread("test.mhd", itk.F)
parameter_object = itk.ParameterObject.New()
parameter_object.ReadParameterFile('rigid.txt')
parameter_object.SetParameter(0, "MaximumNumberOfIterations", "1")
starttime = time.time()
itk.elastix_registration_method(fixed, fixed, parameter_object=parameter_object, log_to_console=True)
print(time.time() - starttime)

The slowdown can be really large. It seems to depend on the number of files of the DICOM series, but the duration of a registration can go up from 8 seconds to more than 40 seconds. The problem was encountered when reading a series of 408 T2 weighted *.dcm files from https://www.kaggle.com/competitions/rsna-miccai-brain-tumor-radiogenomic-classification/data Running on Windows.

Is this a known issue? Do you have any suggestion how to further narrow the reproducing example, and how to find the cause of the issue?

[dzenanz]

The only thing which comes to mind would be image lingering in memory, causing disk swapping during registration. But 400 slices probably can't do that due to small size. So I am out of ideas.

[N-Dekker]

Thanks @dzenanz Interesting hypothesis. I was actually thinking that the reading might keep threads from the thread pool "occupied", even after having finished reading. But I haven't been able to find enough evidence for that idea.

[ntatsisk]

The only thing which comes to mind would be image lingering in memory, causing disk swapping during registration. But 400 slices probably can't do that due to small size. So I am out of ideas.

Yes, we checked that but I think it is unlikely to be the problem. During registration, the memory never exceeds 20% while the CPU is 100%. The total RAM is 128GB btw. That's why we are considering the "threads" hypothesis as Niels mentioned.

[thewtex]

Please try reading the dicom series with itkwasm-dicom, then convert to itk.Image as documented here.