⚠

NOTICE! This is a static HTML version of a legacy Fiji BugZilla bug.

The Fiji project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Bug 398 - TrakEM2 unbearably slow in delivering the first dialog for montaging multiple layers
TrakEM2 unbearably slow in delivering the first dialog for montaging multiple...
Status: RESOLVED FIXED
Product: Fiji
Classification: Unclassified
Component: TrakEM2
unspecified
PC Linux
: P2 normal
Assigned To: Albert Cardona
Depends on:
Blocks:
 
Reported: 2012-01-23 14:03 CST by Stephan Saalfeld
Modified: 2012-04-21 16:51 CDT
0 users

See Also:
Description Stephan Saalfeld 2012-01-23 14:03:42 CST 
TrakEM2 is unbearable slow in delivering the first dialog for montaging multiple layers if the images in the layers already have a coordinate transform.  This happened to me in the VNC dataset, 458 layers, 33,000 images overall.  One CPU is loaded 100% for several minutes until, finally, the dialog appears that offers to choose between montaging modes.  After that, everything works smoothly again.
Comment 1 Albert Cardona 2012-01-23 22:03:26 CST 
(In reply to comment #0)
> TrakEM2 is unbearable slow in delivering the first dialog for montaging
> multiple layers if the images in the layers already have a coordinate
> transform.  This happened to me in the VNC dataset, 458 layers, 33,000 images
> overall.  One CPU is loaded 100% for several minutes until, finally, the dialog
> appears that offers to choose between montaging modes.  After that, everything
> works smoothly again.


It's the undo system:

Display.java:5054
final Collection<Displayable> col = getLayerSet().addTransformStepWithDataForAll(layers);

... which copies the transforms of all images in the range of layers.

The problem would still exist if the coordinate transforms existed in files, although it could be deferred to writing time.

Yes, there isn't a transactional database without TrakEM2 and it is hurting now.
Comment 2 Johannes Schindelin 2012-04-20 22:41:53 CDT 
Adjusting the status to reality.
Comment 3 Albert Cardona 2012-04-20 23:08:58 CDT 
Additionally, the error cannot be reproduced.
Comment 4 Stephan Saalfeld 2012-04-21 16:50:58 CDT 
Sorry---it's the second dialog and we had an offline discussion about it Albert.  You were able to reproduce it and pointed out that it was due to the undo-system creating an enormous amount of CoordinateTransform copies that were partially implemented by String-export-import.  Meanwhile, Albert has replaced several copy methods by a version that does not go through String export and import by which the problem is expected to be removed or at least greatly reduced.  Changing to FIXED for that reason.