Performance is better in my dev environment than stock Fiji

BoneJ’s connected components algorithm uses a couple of tricks to improve performance, like multithreading and Eclipse Collections. In my dev environment it completes a 2048³ px test image in 35-40s. The same code compiled and run on the same JDK & machine in typical user Fiji takes 60-90s to complete the same job, a performance hit of 50-100%.

The only real difference I can think of is that my dev Fiji installation is getting newer versions of some jars from Maven than those which are distributed via the ImageJ update sites to my user Fiji installation. But it’s really not clear which libraries might be the slow ones, since ConnectedComponents imports only these:

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;

import org.bonej.util.Multithreader;
import org.eclipse.collections.api.iterator.IntIterator;
import org.eclipse.collections.api.iterator.MutableIntIterator;
import org.eclipse.collections.api.list.MutableList;
import org.eclipse.collections.api.tuple.primitive.IntObjectPair;
import org.eclipse.collections.impl.list.mutable.FastList;
import org.eclipse.collections.impl.map.mutable.primitive.IntIntHashMap;
import org.eclipse.collections.impl.map.mutable.primitive.IntObjectHashMap;
import org.eclipse.collections.impl.set.mutable.primitive.IntHashSet;

import ij.ImagePlus;
import ij.ImageStack;
import ij.process.ImageProcessor;

Any clues?

User version on left, dev version on right:

1 Like

How about the config in Edit > Options > Memory & Threads?

1 Like

Nearly the same, both 40 threads and 212885 MB or 256000 MB max memory (should not make a difference as image data size is typically 8 GB)

1 Like

These jars are “same but different” between update site (user) and maven-provided (dev) environments:

These jars have version changes or are present in only one of user or dev environments:

Could VisualVM help? I’ve found VisualVM’s CPU sampling very helpful for tracking down bottlenecks.

1 Like

Maybe. I suspect it may just be a case of waiting for the jar versions to get bumped in the updater and then send out to users. Trying to figure out which one it is might not help in any constructive way, except as a point of curiosity.