SimpleITK getting slower with intense working (JAVA) (memory leak?)

[SaluRamos]

SimpleITK getting slower with intense working (JAVA) (memory leak?)

[SaluRamos]

Hi @blowekamp.

I removed JAVAFX, and did some tests and found the source of the problem is this line: byte[] oldPixels = volumeToByteArray(tempImage);

private byte[] volumeToByteArray (Image image) {
        ByteBuffer imageDataBuffer = image.getBufferAsByteBuffer();
        byte[] imageByteArray = new byte[imageDataBuffer.remaining()];
        imageDataBuffer.get(imageByteArray);
        return imageByteArray;
    }

it is possible to reproduce without JAVAFX.

[blowekamp]

Thank you for the bug report. Are you able to reproduce the issue with out javafx?

[SaluRamos]

It seems that there is a residue generated at the beginning of the first 510/520 images.
I implemented a max/min ms count.

this is the slow point where it starts to get super slow

then after it reaches the peak of slowness, i run GC manually from JProfiler (there is a button for this).
The ms drops instantly .

After rendering a long time, remains stable.

[dave3d]

I'm not a Java person, but could you force the garbage collector to run every time?

[SaluRamos]

yes you could call GC anytime with System.gc(), i made a temporary solution for me that runs in a thread.

private void gcThread () {
        int minIntendedFPS = 20;
        long minIntendedRenderTime = 1000/minIntendedFPS;
        try {
            while (true) {
                if (this.renderTime > minIntendedRenderTime) {
                    System.out.println("performing GC");
                    System.gc();
                    Thread.sleep(500);
                }
                Thread.sleep(100);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

[blowekamp]

I'm not a Java person, but could you force the garbage collector to run every time?

I don' think that should be needed.?

Here is the wrapping code related to getting the buffer in JAVA. Maybe you can gain some insight or see a way to improve the code:

SimpleITK/Wrapping/Java/Java.i

Lines 37 to 109 in 46bf97c

	%typemap(jni) void * itk::simple::Image::GetBufferAsVoid() "jobject"
	%typemap(jtype) void * itk::simple::Image::GetBufferAsVoid() "java.nio.ByteBuffer"
	%typemap(jstype) void * itk::simple::Image::GetBufferAsVoid() "java.nio.ByteBuffer"
	%typemap(javaout) void * itk::simple::Image::GetBufferAsVoid() {
	return $jnicall;
	}
	%typemap(out) void * itk::simple::Image::GetBufferAsVoid() {
	const size_t size = arg1->GetNumberOfPixels()*arg1->GetNumberOfComponentsPerPixel()*arg1->GetSizeOfPixelComponent();
	$result = JCALL2(NewDirectByteBuffer, jenv, $1, size);
	}
	%ignore itk::simple::Image::GetBufferAsInt8();
	%ignore itk::simple::Image::GetBufferAsUInt8();
	%ignore itk::simple::Image::GetBufferAsInt16();
	%ignore itk::simple::Image::GetBufferAsUInt16();
	%ignore itk::simple::Image::GetBufferAsInt32();
	%ignore itk::simple::Image::GetBufferAsUInt32();
	%ignore itk::simple::Image::GetBufferAsInt64();
	%ignore itk::simple::Image::GetBufferAsUInt64();
	%ignore itk::simple::Image::GetBufferAsFloat();
	%ignore itk::simple::Image::GetBufferAsDouble();
	%ignore itk::simple::Image::GetBufferAsVoid( ) const;
	%rename( getBufferAsByteBuffer ) itk::simple::Image::GetBufferAsVoid;
	%extend itk::simple::Image {
	long long GetBufferAsNativePointer() { return reinterpret_cast<long long>(self->GetBufferAsVoid()); }
	}
	%typemap(javacode) itk::simple::Image %{
	/** Return a Buffer object for the Image's buffer.
	*
	* If the image's pixel component type is available in Java, then the return object
	* is the appropriate derived object from the Buffer class.
	*/
	public java.nio.Buffer getBufferAsBuffer()
	{
	java.nio.ByteBuffer b = getBufferAsByteBuffer();
	if (getPixelID() == PixelIDValueEnum.sitkInt16 ||
	getPixelID() == PixelIDValueEnum.sitkVectorInt16)
	{
	return b.asShortBuffer();
	}
	if (getPixelID() == PixelIDValueEnum.sitkUInt16 ||
	getPixelID() == PixelIDValueEnum.sitkVectorUInt16)
	{
	return b.asCharBuffer();
	}
	if (getPixelID() == PixelIDValueEnum.sitkInt32 ||
	getPixelID() == PixelIDValueEnum.sitkVectorInt32)
	{
	return b.asIntBuffer();
	}
	if (getPixelID() == PixelIDValueEnum.sitkFloat32 ||
	getPixelID() == PixelIDValueEnum.sitkComplexFloat32 ||
	getPixelID() == PixelIDValueEnum.sitkVectorFloat32)
	{
	return b.asFloatBuffer();
	}
	if (getPixelID() == PixelIDValueEnum.sitkFloat64 ||
	getPixelID() == PixelIDValueEnum.sitkComplexFloat64 ||
	getPixelID() == PixelIDValueEnum.sitkVectorFloat64)
	{
	return b.asDoubleBuffer();
	}
	// sitkInt8 and sitkVectorInt8 are returned as ByteBuffer too.
	return b;
	}
	%}

[dave3d]

I thought in the past the issue with Java was that you'd delete objects, but then the garbage collector wouldn't kick in til later. It would be doing memory management on a bunch of deleted objects all at once, leading to very uneven performance for real-time sort of applications.

[SaluRamos]

Hi @dave3d and @blowekamp,

in fact all simpleitk filters become slow over time, some more than others. I found that setting setNumberOfWorkUnits(1) for the filters makes them massively speed up and never slow down. So default workUnits is causing problems, and since there is almost no documentation for Java...

[SaluRamos]

6 months ago I was also having a problem related to performance with ImageSeriesReader, I reported it on itk.org but we were unable to reach any conclusion, it is likely that the case now has some relation?

https://discourse.itk.org/t/simpleitk-incremental-loading-java/6089/9?u=salu_ramos

[blowekamp]

in fact all simpleitk filters become slow over time, some more than others. I found that setting setNumberOfWorkUnits(1) for the filters makes them massively speed up and never slow down. So default workUnits is causing problems, and since there is almost no documentation for Java...

For these other filter, Is there a slow down if you are only using SimpleITK code and not doing buffer access? If so that points more to memory management (or threading) issues in the JAVA and the JNI.

You can find SimpleITK documentation on SetNumberOfWorkUnits here. The concepts of ITK threading should be converted in the ITK documentation ( but I can't find a good link right now).

[SaluRamos]

For these other filter, Is there a slow down if you are only using SimpleITK code and not doing buffer access?

yes.