ImageJ Plug-in - Extreme (10x) Execution Time Variability.

[Richard VanMetter]

I have successfully written many plug-ins over the past few years. Being
able to use ImageJ to demonstrate image processing concepts to clients
has become a very valuable tool. Recently, I have encountered a very
strange problem when executing an ImageJ plugin. It is without exception
the strangest in 40 years of programming. Let me give some details:

1. the plug-in does interpolation and enlargement of an image as needed
for implementation of the Burt & Adelson Laplacian-pyramid image
encoding. The interpolation kernel is 5x5 and the enlargement is by a
factor of two in both dimensions.
2. To apply the interpolation kernel, I divide the image into 9 regions;
the four corners, the four sides and the center. For the corners and
sides the interpolation is modified to accommodate the lack of data
beyond the edges of the image. Thus, the program has 9 independent
sections - one for each region of the image.
3. Section 9 treats the four pixels in the lower-right corner of the
image. This section chooses among four slightly different methods
depending on whether the enlarged (output) image is to have an even or
odd number of rows and columns.
4. The problem has to do with the execution time for section 5 (the
center region and by far the largest portion of the image). This section
of the code finishes executing long before the code for section 9 is
reached!
     - if section 9 is omitted from the code, the execution time for
section 5 of a 3001x3001 output image is ~ 600 ms
     - if section 9 is present in the code, the execution time for
section 5 is ~ 7000 ms or 7 seconds.
     - I have isolated the behavior to certain lines if section 9.
     - I can switch this time from 600 to 7000 ms repeatably by
commenting and un-commenting as little as a single line of code in
section 9.
     - I have tried re-typing one of the 'offending' lines of code
without solving the problem.

When the problem was first encountered, I had been running JDK version
16 on my WindowsXP laptop. I upgraded to the latest Java Development
Environment 1.6 version 25 without affecting the problem. Finally, I
de-installed all Java runtime and development environments as well as
ImageJ, followed by a fresh install of Download ImageJ 1.44 bundled with
32-bit Java 1.6.0_20 (28MB)from the ImageJ Download page. None of these
actions have affected to above behavior...

I also have done these tests on my older Linux (UBUNTU 10.4) desktop
machine, running an older version of ImageJ (1.44i) with Java 1.6.0_05
(32-bit) .... with very similar results. In this case, execution times
were ~12.5 sec with the 'offending statements' and ~1.0 sec without.

I am at my wits end.... Any suggestions would be greatly appreciated.

Rich..
--

Richard VanMetter
252 Walnut Street NW
Washington, DC 20012
[hidden email]
https://sites.google.com/site/vanmetter/
202-556-3142(w)
202-291-0779(h)

Have a Bright day!

(A 'Bright' is an individual whose worldview is naturalistic, free from supernatural and mystical elements.)
The Brights Website  <http://the-brights.net/>

[Stephan Saalfeld]

Hi Rich,

try setting

-XX:MaxInlineSize=

to more than the default (35) and please report back if that has any
effect.  This JVM parameter sets the maximum bytecode size of a method
to be inlined.

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

Just for curiosity, what is the line doing that you have commented?

Good luck,
Stephan



On Wed, 2011-05-04 at 11:08 -0400, Richard VanMetter wrote:

> I have successfully written many plug-ins over the past few years. Being
> able to use ImageJ to demonstrate image processing concepts to clients
> has become a very valuable tool. Recently, I have encountered a very
> strange problem when executing an ImageJ plugin. It is without exception
> the strangest in 40 years of programming. Let me give some details:
>
> 1. the plug-in does interpolation and enlargement of an image as needed
> for implementation of the Burt & Adelson Laplacian-pyramid image
> encoding. The interpolation kernel is 5x5 and the enlargement is by a
> factor of two in both dimensions.
> 2. To apply the interpolation kernel, I divide the image into 9 regions;
> the four corners, the four sides and the center. For the corners and
> sides the interpolation is modified to accommodate the lack of data
> beyond the edges of the image. Thus, the program has 9 independent
> sections - one for each region of the image.
> 3. Section 9 treats the four pixels in the lower-right corner of the
> image. This section chooses among four slightly different methods
> depending on whether the enlarged (output) image is to have an even or
> odd number of rows and columns.
> 4. The problem has to do with the execution time for section 5 (the
> center region and by far the largest portion of the image). This section
> of the code finishes executing long before the code for section 9 is
> reached!
>      - if section 9 is omitted from the code, the execution time for
> section 5 of a 3001x3001 output image is ~ 600 ms
>      - if section 9 is present in the code, the execution time for
> section 5 is ~ 7000 ms or 7 seconds.
>      - I have isolated the behavior to certain lines if section 9.
>      - I can switch this time from 600 to 7000 ms repeatably by
> commenting and un-commenting as little as a single line of code in
> section 9.
>      - I have tried re-typing one of the 'offending' lines of code
> without solving the problem.
>
> When the problem was first encountered, I had been running JDK version
> 16 on my WindowsXP laptop. I upgraded to the latest Java Development
> Environment 1.6 version 25 without affecting the problem. Finally, I
> de-installed all Java runtime and development environments as well as
> ImageJ, followed by a fresh install of Download ImageJ 1.44 bundled with
> 32-bit Java 1.6.0_20 (28MB)from the ImageJ Download page. None of these
> actions have affected to above behavior...
>
> I also have done these tests on my older Linux (UBUNTU 10.4) desktop
> machine, running an older version of ImageJ (1.44i) with Java 1.6.0_05
> (32-bit) .... with very similar results. In this case, execution times
> were ~12.5 sec with the 'offending statements' and ~1.0 sec without.
>
> I am at my wits end.... Any suggestions would be greatly appreciated.
>
> Rich..