IJ under linux performance problem

[Gabriel Landini]

Hi,
I think I may have mentioned if before. Running ImageJ 1.39d under opensuse
with Java 1.6.0_02-ea I have the following performance problem:

I open the mri-stack sample and convert it from stack to images (i.e. 27
images open).
If I do some operation on one of the images (like a Multiply by 2, or a
Maximum filter) then IJ starts to behave very slow.
For the Math dialog "Multiply" to appear it takes 6 seconds or so. Anything
that shows a dialog, takes approximately this time to open.

Then when I try to close the processed window, the "Save changes?" window
takes another 5 sec to appear. However, closing the other images -which have
not been processed  and do not show a dialog- close quite quickly.

The macro below works fine and reports 256 ms to close the processed image in
my machine (P4, 2GHz).

run("MRI Stack (528K)");
run("Convert Stack to Images");
selectWindow("mri-stack-0001");
run("Multiply...", "value=2");
t=getTime();
close();
print("time: "+getTime()-t);

However doing it by hand (the first 4 lines) introduces the delays mentioned
abovE, and it seems that the more images, the longer the delay (with 54
images this is about 12 sec delay!). It happens every time I try.

Has anybody seen this behaviour?
Where should one start to solve this problem?

Java 1.5.0 does not seem to be affected, but there are some advantages in
using 1.6.0: less memory use when loading 8 bit and RGB images (so it would
be a shame not to take advantage of it).

Thanks in advance.

Gabriel

[ctrueden]

Hi Gabriel,

Unfortunately, I don't have time to test ImageJ + Java 1.6 under Linux
right now, but one thing I can think of to try is to launch ImageJ
from the command line with the run script, perform some operation that
results in excessive lag, then hit Ctrl+\ in the console window a
couple of times to receive some stack traces. These will give you a
snapshot into what the program is doing during the slowdown. I would
also suggest watching CPU usage to see if it is spiking to 100%, or
just idling, as that might shed some light on the nature of the
problem.

Once you know which lines of code are causing the problem, you can
debug things further. Though it might uncover subtle bugs in ImageJ
that you could fix, it is more likely that there is something funny
about certain API calls in 1.6 that are resulting in the slowdown. In
that case, you could work around the issue by recoding that section of
the program to avoid the problematic function calls, or you could
search the web for more information, since it is likely to be
something others have already noticed for other applications.

Good luck,
Curtis

On 8/29/07, Gabriel Landini <[hidden email]> wrote:

> Hi,
> I think I may have mentioned if before. Running ImageJ 1.39d under opensuse
> with Java 1.6.0_02-ea I have the following performance problem:
>
> I open the mri-stack sample and convert it from stack to images (i.e. 27
> images open).
> If I do some operation on one of the images (like a Multiply by 2, or a
> Maximum filter) then IJ starts to behave very slow.
> For the Math dialog "Multiply" to appear it takes 6 seconds or so. Anything
> that shows a dialog, takes approximately this time to open.
>
> Then when I try to close the processed window, the "Save changes?" window
> takes another 5 sec to appear. However, closing the other images -which have
> not been processed  and do not show a dialog- close quite quickly.
>
> The macro below works fine and reports 256 ms to close the processed image in
> my machine (P4, 2GHz).
>
> run("MRI Stack (528K)");
> run("Convert Stack to Images");
> selectWindow("mri-stack-0001");
> run("Multiply...", "value=2");
> t=getTime();
> close();
> print("time: "+getTime()-t);
>
> However doing it by hand (the first 4 lines) introduces the delays mentioned
> abovE, and it seems that the more images, the longer the delay (with 54
> images this is about 12 sec delay!). It happens every time I try.
>
> Has anybody seen this behaviour?
> Where should one start to solve this problem?
>
> Java 1.5.0 does not seem to be affected, but there are some advantages in
> using 1.6.0: less memory use when loading 8 bit and RGB images (so it would
> be a shame not to take advantage of it).
>
> Thanks in advance.
>
> Gabriel
>

[Gabriel Landini]

Thanks Curtis for the tips. I will have a look.
I have the suspicion that this is some weird behaviour introduced in Java 1.6
(because 1.5 seems fine). I tried 1.7 but images lock non stop (I guess it is
too early version).

Unfortunately IJ becomes quite unusable when there are many images open.

Cheers,

G.

[Justin McGrath]

If I run 1.39d using 1.6 on openSuSE 10.0, a similar thing happens
(doesn't take 5 seconds, but it's still slower than using 1.5).
However, I don't know what would cause it or how to go about fixing
it.

Justin

On 8/30/07, Gabriel Landini <[hidden email]> wrote:

> Thanks Curtis for the tips. I will have a look.
> I have the suspicion that this is some weird behaviour introduced in Java 1.6
> (because 1.5 seems fine). I tried 1.7 but images lock non stop (I guess it is
> too early version).
>
> Unfortunately IJ becomes quite unusable when there are many images open.
>
> Cheers,
>
> G.
>

[Albert Cardona]

Gabriel,

I use java 1.6.0 in linux with zero problems. On the contrary, I strongly recommend 1.6.0 to anyone running linux.
This is my java -version  output (one 64-bit, one 32-bit):

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)

java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) 32-Bit Server VM (build 1.6.0-b105, mixed mode)


I have not followed on exactly what macros/plugins are you running. If you let me know exactly which sequence of events (exact images involved, plugins, macros, etc.) I can debug them here in my systems.

Albert

--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[Albert Cardona]

Gabriel,

I have followed the sequence you mention involving the MRI stack and I can only observe a subsecond delay where you claim 6 seconds.
But then my machine is a core2 quad 2.4 Ghz with 4 Gb DDR3 800 RAM, which can mask away any such delays. Plus I'm running gnome, not kde, if that makes any difference.

One would have to run a profiler and measure where is time spent when the command to close the window or show the dialog is issued.
There are eclipse plugins to do so, which you could run.

There's also ImageJ code that is executed only for java 5 or for java 6. Just search ImageJ source code for calls to IJ.isJava16() to find out where.

Some relevant lines:

ij/process/ByteProcessor.java:71:               if (ij.IJ.isJava16()) return createBufferedImage();
ij/process/ColorProcessor.java:63:              if (ij.IJ.isJava16()) return createBufferedImage();

The above actually shows the reason for the speed ups in 1.6.0: images share the array with the processor instead of duplicating it.
Besides, 1.6.0 automatically hardware-accelerates all or most images.

So much to say that, without a profiler, I remain clueless.


Albert

--
Albert Cardona
http://www.mcdb.ucla.edu/Research/Hartenstein/acardona

[dscho]

Hi,

On Thu, 30 Aug 2007, acardona wrote:

> One would have to run a profiler and measure where is time spent when
> the command to close the window or show the dialog is issued. There are
> eclipse plugins to do so, which you could run.

I have yet to find a profiler which is not to slow, and not too bad at
resolving symbols.  If you find any (not eclipse based; my machine is not
powerful enough to run that beast), please let me know.

Ciao,
Dscho

[Gabriel Landini]

Albert & Justin,

Thanks for your replies.


On Thursday 30 August 2007, acardona wrote:

> java version "1.6.0"
> Java(TM) SE Runtime Environment (build 1.6.0-b105)

Not the same one I am using: 1.6.0_02-ea (this is the current version in:
http://download.java.net/jdk6/binaries/

I just tried wiht the jdk-6-rc-bin-b104-linux-i586-01_nov_2006.bin (I cannot
find the b105 you have) and the delay is still there...
The delay happens while there are many images that have changed and are open.

But I found something else:
I select an image, then call the Process>Math>Multiply dialog (which gets
delayed) and then press Cancel. Now if I try to close that image (which has
NOT been processed because of the cancellation, it nevertheless asks
(delaying again) whether I want to save it. Is this right?

By the way injava 1.6, don't you get the "Help" entry in the menu bar missing?
(i.e. the items cannot be packed in the available space? I need to resize the
IJ window-e them all.

Cheers

Gabriel

[Leon Espinosa]

Perhaps this is linked to the problems described by Gabriel:
I had found some problems when I have tried to swich to java 1.6 with  
a mac (OS X 10.4.10 PPC 4x2,5 Ghz G5 4 Go RAM). It seems to me  
slower, and also the ImageJ.app is not working any more so I must to  
use the terminal window with:
cd /Applications/ImageJ/
java -mx1700m -cp ij.jar ij.ImageJ

Leon





Le 31 août 07 à 12:53, Gabriel Landini a écrit :

> Albert & Justin,
>
> Thanks for your replies.
>
>
> On Thursday 30 August 2007, acardona wrote:
>
>> java version "1.6.0"
>> Java(TM) SE Runtime Environment (build 1.6.0-b105)
>
> Not the same one I am using: 1.6.0_02-ea (this is the current  
> version in:
> http://download.java.net/jdk6/binaries/
>
> I just tried wiht the jdk-6-rc-bin-b104-linux-i586-01_nov_2006.bin  
> (I cannot
> find the b105 you have) and the delay is still there...
> The delay happens while there are many images that have changed and  
> are open.
>
> But I found something else:
> I select an image, then call the Process>Math>Multiply dialog  
> (which gets
> delayed) and then press Cancel. Now if I try to close that image  
> (which has
> NOT been processed because of the cancellation, it nevertheless asks
> (delaying again) whether I want to save it. Is this right?
>
> By the way injava 1.6, don't you get the "Help" entry in the menu  
> bar missing?
> (i.e. the items cannot be packed in the available space? I need to  
> resize the
> IJ window-e them all.
>
> Cheers
>
> Gabriel
>

Leon Espinosa
[hidden email]

Laboratoire des Rickettsies du Pr. RAOULT
UMR CNRS 6020
Fac. de Medecine de la Timone
27 Bd Jean Moulin
13005 Marseille

tel  [phone]
fax [phone]

portable  06 79 25 97 40